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ABSTRACT 


This  thesis  investigates  the  possibility  of  implementing  a  multilevel  secure  local  area  network  on 
a  medium-sized  ship.  In  particular  it  focuses  on  medium-sized  ship  communications  suite  connectivity 
to  a  GateGuard  computer  .system,  and  then  on  incorporating  systems  that  ha\c  been  deseloped  under 
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as  well  as  DoD  and  Navy  directives  is  provided  for  background  on  the  accreditation  requirements  of 
multilevel  secure  systems.  Additionally  two  commercially  available  products,  the  VERDIX  Secure  Local 
Area  Network  and  Trusted  Information  System.s’  XENIX  trusted  operating  .sy.stem  are  reviewed  and 
then  shown  how  they  could  potentially  be  integrated  into  a  shipboard  local  area  network.  A  potential 
configurativin  is  provided  with  reeommendativ)n  for  lurther  study  ol  .system  .ipplication  compatibility. 
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I.  INTRODUCTION 


The  information  age  is  here.  Organizations  with  the  capability  to  rapidly  collect,  procc.ss,  and 
disseminate  information  arc  the  mo.st  succc.ssful  in  today’s  environment.  This  new  era  has  not  only 
affected  the  commercial  business  communitv  but  also  the  militar\.  It  has  been  observed  that  coalition 
military  victory  over  Iraq  was  due,  in  a  large  part,  to  the  allic.s’  ability  to  disrupt  the  Iraqi  command  and 
control  structure. 

A.  B.4CKGROUND 

The  United  States  Navy  is  dependent  upon  the  efficient  flow  of  information  within  its  ships. 
Tactical  information  flow  is  vital  to  combat  readiness  and  mission  success;  yet  non-tactical  information 
flow  should  be  considered  a  primary  contributor  to  mission  readiness.  The  overall  efficient  flow  of 
administrative  information  is  to  enhance  combat  readiness  by  improving  the  flow  of  non-tactical 
communications  vertically,  horizontalh,  and  diagonally  through  out  the  ship.  To  achieve  this  goal  the 
U.S.  Navy  requires  a  .shipboard  management  information  system  ba.sed  on  a  non-tactical  personal 
computer  (PC)  local  area  network  (LAN).  Administrative  workload  for  key  managers  should  be  lessened 
and  the  volume  of  paper  documentation  reduced.  The  latter  feature  will  result  in  a  dollar  co.st  .savings 
(reduced  consumable  supplie.s.  le.ss  demand  on  copiers),  le.ss  weight  and  .storage  space  consumed,  and 
reduction  in  non-productivc  man-hour  expenditures  necessary  to  .support  a  paper-based  information 
system.  (Ref.  1] 

1.  Current  Systems 

Today  the  shipboard  non-tactical  information  flow  resides  in  several  independent 
Automated  Information  Systems  (AIS).  These  systems  arc  normally  centralized  and  parochial,  relying 
on  government-owTicd  and  developed  software.  They  arc  considered  support  systems  and  are  dedicated 
to  functions  such  as  logistic.s,  personnel,  finance,  and  maintenance.  Large  ships  have  been  charactcri7.ed 
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by  a  number  of  indcpendenl,  bul  related  systems.  The.sc  ha\e  typically  not  been  networks,  but 
centralized  data  proce.ssing  .sy.stcms  with  small  ho.sts.  usually  minicomputers,  supporting  any  number  of 
dumb  terminals.  The  rapid  proliferation  i>f  personal  computers,  in  combination  with  the  above  .sy. stems, 
has  made  it  common  to  have  two  or  three  different  terminals  or  computing  devices  in  the  same  work 
space,  each  attached  to  its  own  support  system.  jRcf.  2) 

2.  Prototype  Systems 

The  proliferation  of  different  and  separate  systems  and  the  rapid  advancement  of  data 
communications  technology  has  forced  the  Navy  to  reevaluate  the  way  the  way  they  design  and  procure 
non-tactical  systems.  The  initial  goal  for  the  Navy  is  to  link  as  many  systems  as  possible  onto  a  common 
fiber  backbone.  These  include  a  Shipboard  Wide  integrated  Fault  Tolerant  Network  (SWIFTNET)  on 
USS  YELLOWSTONE  (AD  41),  the  GEORGE  WASHINGTON  Information  System  (GWIS)  on  USS 
GEORGE  WASHINfjTON  (C\'N  7.'^),  and  the  early  development  work  on  the  SN.AP  III  program.  |Rcf. 
21 

a.  SWIFTNET 

Shipboard  Wide  Integrated  Fault  Tolerant  Network  (SWIFTNET)  is  installed  in  the 
USS  YELLOWSTONE  (AD  41).  There  arc  currently  a  number  of  related,  but  separate,  AlSs  on 
YELLOWSTONE.  They  include  (Ref.  2]: 

•  MRMS  -  Maintenance  Resource  Management  System  -  MRMS  supports  maintenance  work  at 
shore  repair  activities.  It  provides  for  automated  work  reque.sts  as  well  as  automated  job  status. 

•  PCRS  -  Personal  Computer  Remote  System  -  PCRS  is  an  automated  me.ssage  handling  .system 
that  allows  messages  to  enter  or  leave  the  syestem  via  a  floppy  disk.  It  is  not  yet  a  distributed  net. 
It  is  the  first  step  in  eliminating  paper  in  the  Mcs,sagc  Center. 

•  SNAP  -  Shipboard  Non-tactical  ADP  Program  -  SNAP  is  an  AlS  that  provides  logistic  support 
services  from  a  centralized  host. 

The  goal  of  SWIFTNET  is  to  provide  a  common  link  for  all  of  these  support  sy.stems. 
as  well  as  an  office  automation  .system.  The  prototype  system  consists  v)f  a  fiber  optic  backbone  of  8- 
strand  fiber  cable  employing  an  FDDI  architecture.  Design  criteria  for  SWIFTNET  included 


cxpcndability,  maintainability,  sunivabiiity.  performance,  throughput,  industry  standards  compliance,  and 
upgradabiiity.  (Ref.  2] 

b.  GWIS 

The  purpose  of  GWIS  is  to  increase  combat  readiness  by  improving  non-tactical 
communications.  The  long  term  objective  is  to  electronically  link  ail  work  centers  and  shipboard  offices 
(approximately  250)  via  a  PC  LAN.  The  LAN  will  contain  the  bridges  into  other  sv'stems,  such  as  SN.AP, 
allowing  a  truly  integrated  non-tactical  information  flow  throughout  the  ship.  LikcSWIFl  NET, GWIS 
will  provide  a  common  backbone,  consi.sting  of  S-sirand  fiber,  that  will  link  .several  independent  syslcr.is 
[Ref.  1]  In  addition  to  SNAP.  (JWIS  will  attempt  to  link  the  following  r.ystems  (Ref.  1); 

•  NALCO.VIIS  -  Naval  Aviation  Command  Management  Information  System  -  N.ALCOMIS 
supports  aviation  logistics  afloat  and  ashore.  Modules  include  material  management,  repair 
management,  and  automated  parts  ordering. 

•  NAVMACS  -  Nav:al  .Modular  Automated  Communication  System  -N.AVM.ACS  is  a  family  of 
automated  communications  sy.stcms  sized  to  the  need  of  individual  ship  types.  It  uses  a  modular 
concept  and  includes  hardware  and  software.  It  is  a  mcs.sagc  processing  system  that  can  route  or 
store  incoming  or  outgoing  messages. 

•  SAMS  -  Shipboard  Automated  Medical  System  -  SAMS  is  a  stand-alone  PC  that  supports  the 
shipboard  medical  department. 

Installation  of  GWIS  is  being  conducted  in  a  three  phase  effort.  Phase  1  will  provide 
hardware  and  links  to  the  c.xecutive  level,  which  is  all  Department  Heads  and  above.  Phase  11  c.vtcnds 
communications  to  the  Division  and  Work  Center  level.  This  will  result  in  the  capability  to  electronically 
process  documentation  from  origin  to  dc.stination  without  interruption,  and  this  will  enhance  both 
vertical  and  horizontal  levels  of  communication.  Pha.se  111  will  eventually  incorporate  the  other  existing 
systems  described  above.  (Ref.  Ij  The  GWIS  will  be  built  around  several  functional  modules  listed  in 
Rgure  1. 

GWIS  is  a  dynamic  attempt  to  provide  a  nccc-ssary  service  to  the  ship's  crew.  It  takes 
advantage  of  commercially  available  technology. "  GWIS  rcprc,scnts  a  valuable  opportunity  to  prototype 
a  modern  information  system  for  warships,  and  hence  make  a  giant  leap  toward  the  Chief  of  Naval 


GWIS  Desired  Functional  Modules 

Correspondence.  Provides  E-Mail,  outgoing  correspondence  review,  distribution  of  incoming 
correspondence  and  action  tracing. 

Readiness  Reporting.  Provides  a  database  for  readiness  reporting,  using/interfacing  with  existing 
software  to  generate  Navy  formatted  readiness  reports.  Provides  daily  department  material  status  report 
to  the  Commanding  Officer  and  Executive  Officer. 

Planning  &  Scheduling.  Assists  in  developing  daily,  weekly,  monthly  and  long  range  plans.  Provides 
format  and  logic  for  producing  the  daily  air  plan  and  weapons  load  plan. 

Project  Management.  Provides  software  to  produce  action  plans  and  manage  milestones  for  complex 
or  large  projects. 

Preventive  Maintenance  Management.  Processes  and  stores  preventive  maintenance  records  and 
generates  reports. 

Inspection  Management.  .Stores  results  of  inspections  and  tracks  corrective  action  measures.  Provides 
tickler  system  for  recurring  inspections.  Additionally,  stores  results  of  /.one  inspection  results  and 
provides  reports  to  the  chain  of  command  on  corrective  action. 

Communications.  Ultimate  goal  is  to  interface  with  NAVMACS  to  provide  electronic  review  and 
release  of  outgoing  messages  and  electronic  distribution  of  incoming  messages  at  locations  not  served 
by  NAVMACS. 

Personnel  Management.  Provides  mid-level  managers  with  the  capability  to  access  master  personnel 
database. 

Electronic  Library.  Electronically  store  all  instructions,  publications,  and  other  reference  material  for 
quick  retrieval. 

Figure  1  Desired  GWIS  functional  modules 


Operation’s  goal  of  a  paperless  .ship."  [Ref.  1] 

c.  Shipboard  Non-taclkal  ADP  Program 

The  Shipboard  Non-tactical  ADP  program  (SNAP)  has  provided  support  services  to 
Navy  ships  since  1978.  SNAP  1  was  designed  for  larger  ships,  such  as  tenders  md  aircraft  carriers,  while 
SNAP  11  is  used  by  smaller  combatants.  SNAP  is  a  ccntrali/cd  .system,  consisting  of  a  host  computer, 
either  the  Honeywell  DPS-6  or  the  Harris  H-300,  linked  to  many  dumb  terminals  throughout  the  ship. 
SNAP  integrates  a  number  of  functional  modules  such  as  parts  support,  maintenance  record  preparation, 
word  processing,  data  base  management,  and  financial  records.  Each  of  these  modules  consists  of 


4 


specially  designed  software,  similar  to  commercial  versions,  but  written  and  maintained  for  exclusive  use 
by  the  Navy.  [Ref.  2) 


The  author’s  personal  experience  is  the  SNAP  11  .system  can  be  characterized  as 
inflexible  and  unresponsive  to  user  needs.  In  1986,  a  post  implementation  review  of  user  concerns 
concerning  SNAP  11  was  conducted  by  Wheeler,  Mallon,  and  Shotwell  [Ref.  3]  in  which  they 
concluded  the  SNAP  hardware  and  implementation  support  services  were  adequate  for  the  time. 
However,  lack  of  training  for  end  users  was  considered  a  .significant  problem.  The  authors  recommended 
more  efficient  use  of  the  .sy.stem  could  be  corrected  by: 

•  Better  communication  with  the  end  user 

•  Revision  of  training  policy 

•  Revision  of  documentation  to  a  more  user  friendly  format 

•  Identification  of  a  central  control  point  for  program  policy,  guidance,  and  standards. 

Although  the  author  agrees  with  the  intent  of  the  conclusions,  several  observations 
are  offered.  The  six  ships  on  which  they  conducted  their  survey  had  relatively  recent  SNAP  II 
installations.  The  reported  interviews  indicated  all  Supply  Officers  were  extremely  satisfied  with  the 
system.  In  this  author’s  opinion  this  was  to  be  expected  as  the  Suppl)  function  was  the  one  function  that 
reaped  the  most  benefit  from  the  sy.stem.  Tracking  supply  requisitions  and  inventory  control  transitioned 
from  a  paper-ba.sed  to  a  computer  based  sy.stem.  The  SNAP  II  .system  did  not  greatly  help  any  other 
shipboard  departments  perform  their  respective  function  in  near  the  magnitude  as  Supply  (although  it 
does  provide  a  current  ship’s  maintenance  project).  The  rapid  procurement  and  proliferation  of  personal 
computers  and  commercial  software  during  this  same  time  frame  gave  other  shipboard  departments 
flexibility  in  their  computer  processing  needs.  Most  notably  word  processing.  ([Ref.  3]  reported  that  one 
of  the  biggest  complaints  concerning  SNAP  II  was  the  system  response  time  was  significantly  reduced 
while  word  processing  functions  were  being  performed.) 

SNAP  III  is  expected  to  change  this.  In  fact,  in  1986  Schneidewind  (Ref.  4] 
recommended  that  SNAP  III  be  based  on  commercially  available  hardware  and  software  to  the 
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maximum  extent  possible.  Schneidewind  recognized  that  data  processing  functions  required  for  SNAP 
III  are  not  significantly  different  than  that  required  by  commercial  industry.  He  argued  that  the  Navy’s 
data  processing  functions  can  not  be  truly  unique  as  there  are  a  finite  number  of  functions  that  can  be 
performed  by  any  application.  Major  recommendations  the  report  made  include: 

•  Transition  from  minicomputer  to  microcomputer  system 

•  Transition  to  proven  eommercial  office  .system 

•  Use  local  area  network  technology 

•  Acquire  ma.ss  storage  capability 

•  Acquire  improved  graphics  capability 

•  Consider  automating  ship  --  shore  eommunications 

•  Start  to  develop  a  procurement  policy  to  support  acquisition  of  the  above  technology. 

These  recommendations  were  basically  adopted  by  the  Naval  Sea  Systems  Command 
and  it  is  expected  SNAP  Ill  will  lead  the  Nasy  into  a  truly  distributed,  PC-based,  local  area  network  and 
will  lead  the  Nasy  to  it’s  ultimate  goal  for  a  papcrle.ss  ship. 

It  is  expected  SNAP  111  will  utilize  SAFENET,  the  Survivabic,  Adaptable  Fiber  optic 
Embedded  local  area  NETwork.  SAFENET  is  a  network  protocol  that  utilizes  a  dual  redundant  token 
ring  architecture  that  is  ideal  for  the  type  of  fault  tolerant  requirements  the  Navy  demands.  SAFENET 
1  was  compliant  with  IEEE  802.5.  SAFENET  II,  which  will  be  used  for  SNAP  Ill,  will  be  ANSI  FDDl 
compatible.  [Ref.  2| 

SNAP  III  is  still  in  the  development  process.  A  prototype  system,  called  Micro-SNAP, 
will  be  placed  aboard  several  vessels  in  1991.  Additionally,  several  ships  have  had  prototype  paperless 
ship  systems  on  board  for  the  past  three  years.  Lessons  learned  from  these  efforts  should  make  the  final 
development  and  transition  to  SNAP  III  efficient  and  cost  effective.  [Ref.  2] 
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B.  THE  PROBLEMS 


The  three  projects  discussed  above  represent  an  important  problem  within  the  Navy.  Each  of  the 
projects  are  serious,  well-thought-out  solutions  to  real  problems,  and  each  is  valid  in  its  own  right. 
However,  they  represent  three  similar,  but  distinct  ways  of  solving  the  same  problem.  In  luCt,  these  are 
only  three  well-documented  solutions.  They  do  not  account  for  numerous  other  projects  that  have  been 
initiated  by  individual  commands  in  installing  shipboard  LANs.  What  is  needed  in  the  long  term  is  a 
coordinated  response,  a  single  solution  that  will  provide  nccc.ssary  services  at  the  lowest  possible  costs. 
Each  project  described  is  an  excellent  first  step.  The  next  .step  must  combine  the  best  efforts  of  these 
sy.stems  into  a  single  integrated  solution. 

Applications  are  the  objective  ol  developing  fiber  optic  LANs  in  the  first  place.  The  functional 
modules  described  for  the  (JWIS  are  an  excellent  crtxss  section  of  what  the  Navy  should  expect  from  any 
network  system.  However,  two  particular  applications  are  critical;  They  are  the  cornerstone  efforts  of 
any  successful  shipboard  system.  These  applications  arc  message  handling  and  an  electronic  publications 
library.  Unfortunately,  both  require  security  considerations  which  have  not  been  satisfactorily  addressed 
or  pursued  for  a  solution. 

1.  Message  Handling 

Any  shipboard  LAN  must  be  capable  of  linking  with  the  ship’s  message  center,  and  the 
LAN  must  be  capable  of  routing  incoming  and  outgoing  messages.  An  Automated  Message  Handling 
System  (AMHS)  provides  enough  benefits  to  easily  pay  for  any  development  and  installation  costs  for 
the  LAN.  An  AMHS  must  be  able  to  route  incoming  messages  to  the  appropriate  personnel  and  offices, 
and  it  must  accept  outgoing  messages  generated  at  the  lowest  level  desired.  In  order  to  fully  exploit  the 
advantages  of  a  LAN  and  AMHS  combination,  the  .system  must  be  capable  of  handling  classified 
message  traffic.  With  the  Navy’s  use  of  classifications,  security  clearances,  and  acce.ss  based  on  need  to 
know,  the  ground  work  is  laid  for  the  requirement  of  a  multi-level  secure  system.  Although  all  the 
previous  projects  have  outlined  the  desire  to  integrate  the  message  center  with  the  appropriate  LAN, 
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this  has  not  been  fully  obtained  due  to  the  lack  of  a  multi-level  secure  system.  To  date,  the  best  solution 
has  been  to  establish  a  system  high  le\el  LAN,  meaning  that  all  nodes,  personnel,  and  data  on  the  LAN 
must  all  be  cleared  to  the  same  level.  Captain  Nutwell.  Commanding  Officer  of  GEORGE 
WASHINGTON,  recently  stated: 

The  hardware  we’re  going  to  have  in  our  non-tactical  network  is  not  multi-level  security  capable 
because  the  computers  aren’t.  If  we  wanted  to  process  Secret,  every  machine  on  the  network 
would  have  to  be  Secret.  I  think  we’ll  continue  to  process  Secret  the  old  way.  [Ref.  5] 

While  in  port,  ships  rely  heavily  on  the  station  infrastructure  for  over  the  counter  message 
traffic,  supply  support,  and  maintenance  support.  Naval  stations  are  in  the  process  of  developing  their 
own  local  area  networks.  The  capability  for  a  shipboard  LAN  to  connect  with  thc.se  shore-  based  LANs 
will  be  greatly  advantageous,  as  ship  repair,  supply,  and  financial  data  will  easily  communicated.  The 
Defense  Message  System  (DMS)  has  developed  a  Multi-level  Mail  Server  (MMS)  .system  that  will 
electronically  transfer  a  ships  message  traffic  from  the  local  Nasal  Telecommunications  Center  to  the 
ship  moored  at  a  local  pier.  This  sy.stem  is  designed  It)  transfer  Uncla.ssified  to  Secret  message  traffic 
to  the  ship.  Again,  an  AMHS  and  shipboard  LAN  capable  of  distributing  all  the  receised  traffic  would 
be  greatly  desired. 

2.  Electronic  Library 

This  is  the  second  critical  step  to  the  Nasy’s  paperle.ss  ship  goal.  Studies  have  show'n  that 
electronic  storage  devices  such  as  CD-ROM  can  reduce  the  weight  of  paper  and  paper  storage  from  14 
to  33%.  On  an  AEGIS-class  guided  missile  cruiser,  this  equates  to  a  sacings  of  about  23,600  pounds. 
[Ref.  2] 

The  Surface  Warfare  Development  Ciroup  (SWDG)  is  a  small  Navy  organization  with 
immense  responsibility.  SWDG  develops  and  evaluates  new  tactics  and  improves  current  tactics  in  the 
surface  Navy’s  three  dimensions  of  warfare:  Anti-Air,  Anti-Surface,  and  Anti-Submarine,  including 
electronic  warfare  as  well  as  command  and  control.  Experimental  tactics  arc  issued  as  TACMEMOS, 
and  later  updated  as  approved  tactics  in  TACNOTES.  Ultimately  these  tactics  are  incorporated  into 


8 


Naval  Warfare  Publicalions  or  a  ship  class  Combat  Systems  Doctrine.  Additionally,  tactical  les.sons 
learned  by  the  fleet  arc  collected  and  compiled  b\  SWDG  in  the  development  proce.ss.  The  entire 
lessons  learned  and  some  NWPs  will  be  coming  out  on  CD-ROMs  and  will  be  available  to  the  fleet  in 
the  near  future.  |Rcf.  6) 

It  has  been  the  author’s  experience  that  these  tactical  information  packages  are  often 
Secret.  The  capabilitv  to  share  these  documents  on  a  multi-level  secure  LAN  will  greatlj  improve  the 
dissemination  of  tactics  to  ship’s  personnel,  increasing  combat  readiness  md  reducing  the  administrative 
burden  of  maintaining  a  large  paper  based  Secret  account. 

C.  PURPOSE 

The  purpose  of  this  thesis  is  to  address  the  feasibility  of  installing  a  multi-level  secure  LAN  on 
a  U.S.  Navy  ship.  The  author  will  focus  on  a  medium-sized  ship,  as  he  has  reached  the  conclusion  that 
only  large  afloat  commands  such  as  aircraft  carriers  and  tenders  will  be  subjected  to  exten.sive  research 
and  development  of  shipboard  LANs.  Also  the  command  entities  of  the  NTS  will  consider  their  job 
complete  once  mes.sages  are  deliveied  to  their  defined  end  user  -  the  ship.  The  author  considers  the  end 
user  to  be  the  various  officers  and  sailors  v)n  the  ve.ssels  that  mu.st  still  drudge  through  a  Secret  paper 
information  .system.  If  a  multi-level  secure  LAN  sv.stem  is  impractieal.  then  one  mu.st  con.sider  two 
separate  shipboard  LANs,  with  one  a  .sy.stem  level  high  of  at  least  Secret.  As  di.scus.sed  above,  there  are 
several  desired  uses  of  a  shipboard  LAN  that  would  require  multi  level  security.  The  author  will  attempt 
to  review  the  various  alternatives  and  provide  a  recommendation  on  the  best  solution. 

D.  ORGANIZATION 

This  thesis  is  organized  into  seven  chapters,  each  presenting  background  information  to 
comprehend  the  task  of  providing  multi-level  security  within  a  LAN.  Chapter  11  provides  a  background 
on  computer  and  data  communications  security  to  provide  an  understanding  of  terminology  and  different 
approaches  to  providing  LAN  security. 


Chapter  111  reviews  the  Nava!  Telecommunications  System  and  discusses  the  required  integration 
of  a  LAN  with  a  shipboard  communications  suite.  A  review  of  current  Navy  pursuit  for  a  shipboard 
LAN  and  communication  suite  is  provided  with  an  a.ssessment  of  the  Navy’s  current  policy. 

Chapter  IV  will  provide  background  information  on  the  Navy's  implementation  of  DMS  and  its 
capabilities.  Procedures  and  hardware  already  in  use  at  shore  facilities  will  be  reviewed  to  determine 
a  shipboard  application. 

Chapter  V  wili  presents  certain  vendor  products  for  multi-level  .secure  LANs.  Specifically, 
VERDIX’s  Secure  Local  Area  Network,  and  Trusted  Information  Sy.stem’s  XENIX  trusted  operating 
system  will  be  reviewed.  The  intent  is  not  to  provide  a  product  endorsement  but  to  review  a  method  of 
providing  multi-level  security. 

Chapter  VI  will  present  a  proposal  for  a  multi-level  secure  shipboard  LAN  utilizing  information 
presented  in  previous  chapters. 

The  final  chapter.  Chapter  Vll,  will  provide  a  summary  and  conclusions.  Again,  the  author  does 
not  intend  to  provide  any  product  endor.sement.  The  conclusions  will  offer  one  option  the  Navy  has  in 
pursuing  the  acquisition  of  a  shipboard  multi-level  secure  LAN. 


It) 


II.  SECURITY  OVERVIEW 


A.  BACKGROUND 

Network  security  can  be  defined  as  the  protection  of  network  resouices  against  unauthorized 
disclosure,  including  accidental  disclosure,  modifications,  rc.strictions,  or  destruction.  Security  has  long 
been  an  object  of  concern  and  subject  to  extensive  research  and  deselopment  for  both  data  processing 
systems  and  communications  facilities.  With  computer  networks  these  concerns  are  combined,  and  for 
local  networks  the  problem  is  most  acute.  (Ref.  7] 

A  full-capacity  local  network  offers  direct  terminal  access  to  the  network  and  data  files  and 
applications  distributed  among  a  \ariet\  of  computing  de\iccs  and/or  dumb  terminals.  The  local  network 
may  also  pro\idc  access  to  and  from  U)ng  haul  ct)mmunications.  Providing  sccurit)  in  this  type  of 
environment  is  most  complex.  (Ref.  7:  p.  .1.36| 

Network  securitv  is  a  broad  subject,  and  encompasses  physical  and  administrative  controls  as  well 
as  automated  ones.  To  ensure  an  understanding  of  terminology  and  concepts  presented  in  follow-on 
chapters,  the  first  portion  of  this  chapter  will  provide  a  functional  de.scription  of  three  areas  of  specific 
concern  for  local  networks: 

•  Access  control 

•  Encryption 

•  Multilevel  security 

1.  Access  controls 

The  purpose  of  acce.ss  control  is  to  ensure  that  only  authorized  users  have  access  to  the 
system  and  its  individual  resources  and  that  acce.ss  to  and  modification  of  particular  portions  of  data  is 
limited  to  authorized  individuals  and  program.s.  Measures  taken  to  control  acce.ss  in  a  data  proce.ssing 
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system  generally  fall  into  two  categories;  first,  those  associated  with  users  or  groups  of  users  and, 
second,  those  associated  with  data.  [Ref.  7:  p.  337] 

a.  Aulhenlicalion 

The  control  of  u.ser  access  is  referred  to  as  authentication.  Authentication  consists 
of  validating  a  user’s  identification  ^ID)  and  password,  either  at  the  network  le\el  or  within  an  individual 
host.  The  ID  validation  process  ensures  a  user  is  enrolled  in  the  validating  sy.stcm.  while  the  password 
validation  ensures  that  the  person  signing  on  is  not  an  imposter.  This  id/passwt)rd  .-.ystem  has  developed 
into  a  notoriously  unreliable  method  of  access  control.  [Ref.  7;  p.  337] 

In  many  local  networks,  tw'o  levels  of  authentication  will  probably  be  used.  Individual 
nodes  may  be  provided  with  a  logon  facility  to  protect  host/node  specific  resources  and  applications. 
Additionally,  the  network  as  a  whole  may  have  protection  to  restrict  network  access  to  authorized  users. 
This  two-level  facility  is  desirable  for  a  local  network  that  connects  disparate  hosts  and  simply  provides 
a  convenient  means  of  terminal  host  access.  (Ref.  7:  p.  338) 

The  difficulty  of  authentication  is  compounded  over  a  mulli-acce.ss  medium  LAN.  The 
logon  dialogue  must  take  place  over  the  communications  medium  and  eavesdropping  is  a  potential 
threat.  The  eavesdropping  threat  can  be  classified  as  passive  and  active  wiretapping.  Passive  wiretapping 
means  observing  the  data  stream  but  not  modifying  it.  The  pa.ssivc  wiretapper  can  read  u.ser  data  and 
also  analyze  LAN  control  data  and  traffic  .statistics.  Active  wiretapping  means  modifying  the  packet 
stream  for  various  effects.  [Ref.  8] 

Additional  access  control  issues  can  be  considered  to  fall  in  two  classes:  partial,  or 
distributed,  access  control  and  full,  or  centralized,  access  control. 

b.  Partial  Access  Control 

Partial  access  control  treats  the  network  as  a  transparent  communication  link  and 
requires  that  the  LAN  deliver  data  to  a  node  only  if  the  data  is  addre.ssed  to  that  node.  This  requires 
the  LAN  to  perform  five  functions  correctly  [Ref.  8|: 
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•  A  source  Network  Interface  Unit  (NIU),  a  NIU  that  receives  data  for  transport  from  its  attached 
node,  knows  with  certainty  the  destination  address  of  the  data  and  correct!)  places  the  address 
in  the  packet. 

•  The  LAN  keeps  packets  separated,  not  mixing  and  delivering  as  one  packet  data  and/or  an 
address  from  two  different  packets. 

•  The  LAN  protects  the  address  against  change  while  the  packet  is  in  transit. 

•  Every  NIU  can  positively  identify  its  attached  node. 

•  No  NIU  delivers  a  packet  recei\ed  from  the  LAN  tran.sport  medium  to  its  attached  node  unless 
the  packet  is  so  addressed. 

c.  Full  Access  Control 

Full  access  coiurt)!  means  that  in  addition  to  partiai  acce.ss  control  the  LAN  transports 
data  from  one  node  to  another  onK  if  the)  are  authoii/ed  to  communicate  [Ref.  8).  In  this  centralized 
approach  the  network  provides  the  logon  sercice.  w’hich  can  be  thought  of  as  being  associated  with  the 
Netw'ork  Control  Center  (NCC).  In  the  case  of  a  LAN,  this  may  be  accomplished  by  setting  up  a 
connection  between  each  inactive  Network  Interface  Unit  and  the  NCC.  When  the  user  activates  a  node 
and  desires  to  access  the  network,  the  connection  is  automatically  to  the  NCC.  After  a  succe.ssfui  logon, 
the  NCC  then  establishes  a  connection  between  the  reque.sting  node  and  the  reque.sted  de.stination 
address.  When  this  connection  is  terminated,  the  original  user  and  NCC  connection  is  reestablished.  A 
similar  technique  would  be  used  in  a  digital  swiich.  A  data  port  off-hook  condition  would  result  in  a 
connection  to  a  logon  .server;  after  authentication,  the  request  connection  would  be  made.  |Ref.  7:  p. 
338) 

d.  Access  Control  Matrix 

After  succc-ssful  authentication,  the  user  is  granted  access  to  a  hi)St  and/or  processes. 
This  is  not  sufficient  for  a  .sy.stcm  that  include.s  scn.sitivc  data  in  its  database.  The  authentication 
procedure  identifies  a  specific  user  with  a  profile  that  specifics  permissible  operations  and  file  accesses. 
The  network  operating  system  can  enforce  rules  based  on  the  user  profile.  However,  the  data  base 
gement  system  must  control  access  to  specific  portion  of  records.  For  example,  it  may  be 
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permissible  for  am  one  in  administration  to  obtain  a  list  of  compan>  personnel,  but  only  certain 
individuals  may  base  access  to  salary  information.  The  issue  in\olves  more  than  one  le%el  of  detail.  The 
network  operating  .system  may  grant  a  user  permi.ssion  to  access  a  file  or  use  an  application  in  which 
there  are  no  further  security  checks,  whereas  the  data  base  management  sy.stem  must  make  a  decision 
on  each  individual  access  attempt.  That  decision  depends  on  the  user’s  identity  and  on  the  specific  parts 
of  the  record  being  accessed.  [Ref.  7:  pp.  337  to  339] 

A  general  model  of  access  control  as  exercised  by  a  data  base  management  system 
is  that  of  an  access  matrix.  One  a.xis  on  the  table  consists  of  identified  subjects  that  may  attempt  data 
access.  Typically,  this  li.st  will  consist  of  individual  users  or  user  groups,  although  acce.ss  could  be 
controlled  for  terminals,  hosts,  or  procc.sscs  in.stcad  of  or  in  addition  to  users.  The  other  axis  lists  the 
objects  that  may  be  acce.ssed.  In  the  greatest  level  of  detail,  objects  may  be  individual  data  fields; 
however,  larger  grouping.s.  such  as  records,  record  type.s,  or  even  an  entire  data  ba.se  may  also  be  objects 
in  the  matrix.  Each  entry  in  the  matrix  indicates  the  acce.ss  rights  of  a  particular  subject  to  a  specific 
object.  [Ref.  7:  pp.  337  to  3.39] 

In  practice,  an  access  control  matrix  is  implemented  by  decompu.sitiun  in  one  of  two 
ways.  The  matrix  may  be  decompo.scd  by  columns,  yielding  acce.ss  control  lists.  For  each  object,  an 
access  control  lists  specified  users  and  their  permitted  acce.ss  opportunities.  Thus  a  user's  name  can  be 
checked  against  the  access  control  list  for  that  resource  to  see  if  and  what  type  of  permission  has  been 
granted.  A  user  must  have  a  valid  network  account  and  the  nece.ssary  permission  to  access  the  object. 
Decomposition  by  rows  yields  capability  tickets.  A  capability  ticket  .specifies  authorized  objects  and 
operations  for  a  user.  This  is  a  type  of  share  level  security,  which  works  by  assigning  a  unique  password, 
capability  ticket,  to  each  shared  re.source  or  database.  Any  u.ser  who  know.s  the  pas.swurd  may  share  that 
resource.  This  is  appropriate  for  environments  that  do  not  require  tight  .security  measures.  [Ref.  7:  pp. 
337  to  344] 

Network  concerns  for  access  control  arc  similar  to  those  of  authentication.  Encryption 
may  be  required  to  ensure  .secure  communications  on  a  LAN.  Typically,  access  control  is  decentralized. 
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that  is,  controlled  by  host-based  data  base  management  systems.  Howe%er,  if  a  network  data  base  server 
exists  on  a  LAN,  access  control  becomes  a  network  function.  [Ref.  7:  p.  340J 
2.  Enct^ption 

In  the  previous  section  eavesdropping  was  discussed  and  broadly  categorized  into  two 
areas,  active  and  passive  wiretapping.  Additionally  eavesdropping  could  be  accomplished  by 
programming  an  NIU  to  accept  packets  other  than  those  addressed  to  it.  An  effective  countermeasure 
is  to  encrypt  the  data  in  each  packet. 

Encryption  conceals  the  meaning  of  data  by  changing  the  intelligible  plaintext  into 
intelligible  cipher  text.  An  encryption  system  consists  of  two  parts;  the  algorithm  which  is  the  set  of  rules 
for  transforming  information,  and  the  key  which  personalizes  the  algorithm  by  making  the 
transformation  of  specific  data  unique.  Different  keys  produce  completely  different  ciphertexts,  therefore 
communicating  parties  must  share  the  same  key.  The  key  is  relatively  small,  in  number  of  bits,  and  can 
be  easily  transported  from  one  node  to  another.  (Ref.  9] 

Encryption  algorithms  may  be  implemented  in  software  and  hardw  arc/firmware.  Software 
advantages  are  mostly  realized  when  protecting  stored  data  files  and  data  in  a  host  computer.  Hardw'arc 
advantages  include:  greater  processing  speeds,  independence  from  communication  protocols,  ability  to 
be  implemented  on  dumb  devices  (terminals,  telex,  facsimile  machines),  and  greater  protection  of  the 
key  because  it  is  physically  locked  in  the  encryption  box.  Tampering  with  the  box  can  cause  erasure  of 
the  keys  and  related  information.  (Ref.  9:  p.  496] 
a.  Data  Encryption  Standard 

The  Data  Encryption  Standard  (DES),  developed  by  the  National  ln.stitutc  of 
Standards  and  Technology  (formerly  the  National  Bureau  of  Standards),  is  based  on  a  conventional 
encryption  scheme.  Original  data  in  plaintexT  is  transformed  to  a  cipher  coded  bit  form  by  means  of  an 
algorithm.  Upon  reception,  the  ciphertcM  is  transformed  back  to  its  original  form  if  the  algorithm  and 
key  art-  know'n  at  the  destination  address.  (Ref.  9:  p.  499] 
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DES  is  a  member  of  a  class  of  algorithms  known  as  symmetric.  This  means  that  the 
key  used  to  decrypt  a  particular  bit  stream  must  be  the  same  as  that  u.scd  to  cncrjpt  it.  Since  the  DES 
algorithm  is  public!)  known,  the  disclosure  of  a  key  ma)  compromise  the  entire  message.  [Ref.  9:  p.  50UJ 
Achieving  key  distribution  can  be  accomplished  in  several  ways.  For  two  nodes  A  and  B: 

•  A  key  could  be  selected  by  A  or  B  and  physically  delivered,  by  courier,  to  the  other  party. 

•  A  third  party  could  select  the  key  and  physically  deliver  it  to  A  and  B. 

•  If  A  and  B  have  previously  and  recently  used  a  key,  one  party  could  transmit  the  new  key  to  the 
other,  encrypted  using  the  old  key. 

•  If  A  and  B  each  have  an  encrypted  connection  to  a  third  party  C,  C  could  deliver  a  key  or  the 
encrypted  links  to  A  and  B. 

The  la.st  course  is  attractive  in  a  LAN  context  and  could  be  handled  by  an  NCC; 
however,  the  keys  u.sed  to  communicate  with  C  would  have  to  be  distributed  by  some  means.  [Ref.  7: 
pp.  340  to  341] 

b.  Public  Key  Encryption 

Public  key  encryption  inherent!)  differs  from  private  key  .sy.slems  such  as  DES.  Public 
keys  are  based  on  a  one  way  function,  data  is  transformed  to  ciphertext  b)  use  of  a  publicly  known 
encryption  key  for  the  destination  address.  Once  the  data  is  cncr)pted  it  cannot  be  taken  apart  unless 
the  corresponding  private  key  of  the  destination  node  is  known.  One  way  functions,  which  are  relatively 
easy  to  calculate  in  one  direction,  arc  computativcly  impossible  to  reverse  without  the  private  key.  In 
other  words,  the  encr)'ption/dccryption  can  be  accomplished  by  a  pair  of  keys  which  create 
transformations  that  arc  the  inverse  of  each  other.  |R(  f.  9;  pp.  500  to  503] 

3.  Multilevel  Security 

Multilevel  data  procc.ssing  can  be  dc.scribed  as  having  data  of  several  different  levels  of 
classification  being  proce.ssed  on  a  single  computer  or  network  at  the  same  time,  while  users  of  different 
clearances  arc  on  the  sy.stem.  For  this  approach  to  work,  the  system  must  be  trusted  to  maintain  the 
separation  of  different  classified  data  and  prevent  u.sers  from  accessing  data  for  which  the)  lack  proper 
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clearance  {Ref.  10).  This  requirement,  based  the  Bell  and  LaPadula  model,  can  be  simply  stated 
in  two  parts.  A  multiple  level  secure  system  must  enforce  [Ref.  7:  pp.  342  to  343]: 

•  No  read  up:  A  user  can  only  read  an  object  of  less  or  equal  security  level. 

•  No  write  down:  A  user  can  only  write  into  an  object  of  greater  or  equal  security  level. 

To  verify  that  a  computer  system  meets  a  promulgated  policy,  computer  security  models 
have  been  developed.  These  models,  in  a  mathematical  manner,  de.scribc  how  to  mediate  the  flow  of 
information  in  an  ADP  cn\-ironmeni  to  and  from  users  and  data  repositories.  The  abstract  mechanism 
that  controls  this  flow  is  known  as  a  reference  monitor.  |Ref.  10)  The  reference  monitor  enforces  the 
security  rules  (no  read  up.  no  write  down)  and  has  the  foilt)wing  properties  |Ref.  7:  pp.  342  to  343J: 

•  Complete  mediation;  The  security  i  uies  are  enforced  on  every  acce.ss.  not  just,  for  c.xamplc,  when 
the  file  is  open. 

•  Isolation:  The  reference  monitor  and  data  base  are  protected  from  unauthorized  modification. 

•  Verifiability:  The  reference  monitor’s  correctness  must  be  provable:  thus  it  must  be  small,  simple, 
and  easy  to  understand. 

In  order  to  accomplish  the  abovr,  computer  operating  systems  were  redesigned  in  the  form 
of  a  hierarchy  of  modules.  The  innermost  level  of  the  hierarchy  has  the  mo.st  privilege  regarding 
executing  code.  As  one  moves  out  from  the  inner  layer  less  privileges  arc  granted  and  fewer  functions 
arc  able  to  be  executed.  The  innermost  level  contains  those  ptirlions  of  the  vvperating  system  that  arc 
most  critical  to  security  need.s,  specifically  access  ctmtrol.  memory,  and  input /output  management.  Taken 
together,  these  pf.rtions  of  the  operating  system  are  knowu  as  the  kernel  of  the  O.S.  In  addition  to  the 
kernel,  the  system  also  includes  trusted  procc.sses;  these  can  run  outside  the  kernel  and  arc  tru.sicd  not 
to  violate  certain  .security  rules  of  the  model.  Taken  together,  the  kernel  and  tru.sicd  procc-sscs  arc 
referred  to  as  the  Trusted  Computing  Base  (TCB).  |Rcf.  10} 

B.  LOCAL  AREA  NETWORK  MULTILEV'EL  SECURm’ 

Several  approaches  to  multilevel  network  security  have  been  proposed  over  the  yrars. 
Approaches  have  involved  many  schemes  and  configurations.  Accordingly,  a  review  is  appropriate. 
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1.  Typical  Network  Configurations 

Consideration  should  be  given  to  various  network  configurations  iinolving  both  trusted  and 
untrusted  systems  with  examination  of  some  typical  connection  scenarios.  This  discussion  will  be  helpful 
in  understanding  specific  network  security  requirements  and  the  evaluation  of  network  security  models. 
The  four  possible  network  configurations  are  as  follows  {Ref.  11]: 

•  Untrusted  computer  systems  on  an  untrusted  network 

•  Trusted  computer  systems  on  an  untrusted  network 

•  Untrusted  computer  systems  on  a  trusted  network 

•  Trusted  systems  on  a  trusted  network 

a.  Case  1:  Untrusted  Computer  Systems  on  an  Untrusted  Network 

In  this  case  the  untrusted  systems  and  untrusted  network  operate  in  a  Dedicated  or 
in  a  System  High  mode.  There  is  no  access  control  policy  for  the  computer  systems  or  the  network,  and 
no  labels  are  associated  with  information  processed  or  transferred  in  the  network.  A  network  or 
computer  TCB  is  not  required.  Users  are  cleared  to  the  ma.\imum  level,  but  information  can  range  from 
some  low  level  to  the  maximum  establi.shed  network  level.  It  is  necessary  to  ensure  information  classified 
above  the  maximum  level  not  combine  with  any  parts  of  the  entire  system.  [Ref.  11) 

b.  Case  2:  Trusted  Computer  Systems  on  an  Untrusted  Network 

The  computer  .systems  arc  trusted  to  operate  in  a  multi-level  mode  including  the 
network  security  level.  Access  control  is  required  within  the  computer  system.  The  computers  TCB  is 
required  to  ensure  that  the  information  is  properly  labeled  with  the  network  high  security  level  and  that 
information  of  a  higher  level  than  the  network  is  not  allowed  to  be  placed  in  the  network.  The  computer 
TCB  must  also  know  the  level  of  other  computer  systems  within  the  network.  [Ref.  11] 

c.  Case  3:  Untrusted  Computer  Systems  on  a  Trusted  Network 

The  computer  systems  connected  to  the  network  operate  in  the  System  High  mode. 
Because  the  network  can  carry  information  of  different  classifications,  it  is  necessary  to  attach  labels 
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either  to  information  units  or  to  \irtual  circuits  when  sessions  arc  established.  Untrusted  computer 
system  levels  must  be  within  the  range  of  levels  for  which  the  network  is  trusted  and  a  network 
mandatory  security  policy  must  be  enforced.  [Ref.  11) 

d.  Case  4:  Trusted  Computer  Systems  on  a  tmsted  Network 

Both  the  computer  systems  and  the  network  operate  in  a  multi-level  mode.  Both  the 
computer  .systems  and  the  network  must  have  TCBs.  Not  all  users  are  cleared  for  all  information  on  the 
network;  therefore,  the  range  of  .security  levels  of  the  computer  .systems  must  overlap  with  the 
corresponding  levels  of  the  network.  Both  sy.sienis  mu.sl  ensure  that  they  only  pass  information  within 
the  corresponding  security  level  range.  This  configuration  also  icquiies  no  illicit  information  flow  and 
that  all  information  is  correctly  labeled.  [Ref.  11) 

2.  Typical  Network  Security  Approuclies 

Approaches  closely  parallel  configurations,  but  there  are  slight  differences.  Approaches 
that  have  surfaced  over  the  years  include  [Ref.  7  p.  344): 

1.  Physical  separation:  The  security  problem  disappears  if  the  various  LANs  are  in  separated  areas 
and  protected  at  their  designated  security  levels.  This  approach  negates  most  of  the  benefit  of  the 
LAN.  Connecti\'ily  is  limited.  Security  requirements  permit  data  to  be  passed  upward  (from  a  lower 
to  higher  classification  area),  but  this  approach  docs  not  facilitate  such  data  transfer. 

2.  Bandw'idth  separation:  With  a  broadband  cable,  each  classification  level  could  be  assigned  a 
separate  channel.  Cross  channel  traffic  could  be  supported  by  a  multilevel  secure  host.  A  trusted 
multilevel  host  is  required. 

3.  Encryption:  Each  NIU  would  require  encryption  capability,  reiiuiring  a  trusted  facility  for 
distributing  keys  to  end  points  requesting  a  connection 

4.  Trusted  hosts:  Liberal  use  of  trusted  host  machines  (Guards)  may  be  capable  of  satisfying  security 
requirements.  If  the  trusted  host  were  a  minicomputer,  mainframes  could  be  connected  by  a  trusted 
front  end.  Terminal  would  have  to  interface  to  the  network  via  a  trusted  host. 

5.  Trusted  NIU:  This  is  an  NIU  that  provides  a  reference  monitor  capability.  This  NIU  may  also  be 
referred  to  as  a  Trusted  Interface  Unit  (TIU).  It  is  a  remarkably  simple  device. 

Each  approach  is  unique,  however  some  are  more  advantageous  than  others.  Of  the  five 

approaches  listed  above,  encryption  and  the  TlL's  arc  considered,  by  the  author,  to  be  most  appropriate 

to  a  shipboard  environment  and  subsequent  attention  will  be  focused  in  these  areas.  Additionally,  the 
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first  alternative  of  physical  separation,  ma>  be  a  \iable  allernalixe  for  shipboard  application 
requirements. 

a.  Trusted  Interface  Units 

The  Trusted  Interface  Unit  (TiU)  is  a  piece  of  firmware  that  performs  all  the 
functions  of  a  an  ordinary  NIU;  however,  it  is  designed  to  operate  at  an  assigned  security  level.  Two 
other  functions  are  required: 

•  The  TIU  will  label  each  frame  that  it  transmits  with  its  security  level. 

•  The  TIU  will  accept  only  frames  that  are  labeled  with  its  own  or  lesser  security  level. 

TlU’s  were  originally  conceived  to  be  designed  and  produced  in  three  versions,  in 
increasing  order  of  comple.xily.  A  single  level  TIU  is  set  to  monitor  a  single  security  level.  The  TIU  must 
be  physically  protected  to  the  network-high  level,  and  is  designed  to  reliably  isolate  the  traffic  at  one 
particular  security  level  frttm  traffic  at  all  other  levels.  A  variable  level  TIU  is  similar  to  a  single  level 
TIU,  except  the  operator  can  change  the  level  of  the  TIU  by  adjusting  eicctronicall)  linked  terminal 
switches  or  keyboaid  kejs.  The  range  of  adjustments  correspond  to  the  approved  security  levels  fitr  that 
particular  TIU  and  terminal.  A  multilevel  TIU  requires  fully  trusted  software;  however,  a  network  can 
operate  in  a  multilevel  mode  using  only  single  and/or  variable  level  TIUs.  See  Figure  2. 
[Ref.  12] 

b.  Network  Encryption 

With  either  of  the  encryption  approaches  previously  described,  network  encryption 
can  be  end-to-end  or  link  orientated.  End-to-end  encryption  is  handled  by  the  processes  at  each  end  of 
the  session.  In  this  capacity  encryption  becomes  a  presentation  layer  function.  This  approach  allows 
certain  flexibility  within  the  LAN,  allowing  encryption  devices  to  be  installed  on  selected  nodes.  The 
other  approach  is  to  encrypt  at  the  link  level.  Data  plus  all  headers,  except  the  layer  2  header  are 
encrypted.  This  encryption  capability  can  be  incorporated  into  a  NIU.  |Rcf  7:  p.  .'142] 
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Figure  2  Example  of  local  area  nelwork  ulilixing  TlUs 

C.  DEPARTMENT  OF  DEFENSE  COMPUTER  SECURITY  REQUIREMENTS 

In  December  of  1985,  the  U.S.  Department  of  Defense  published  the  Trusted  Computer  System 
Evaluation  Criteria  (TCSEC),  commonly  known  as  the  Orange  Book.  The  TCSEC  is  u.sed  to  evaluate 
the  effectiveness  of  security  controls  built  into  automatic  data  processing  system  products  [Ref.  11].  "The 
basic  philosophy  of  the  protection  described  in  the  TCSEC  requires  that  the  access  of  subjects  (i.e., 
human  users  or  processes  acting  on  their  behalf)  to  objects  (i.e.,  containers  of  information)  be  mediated 
in  accordance  with  an  explicit  and  well  defined  security  policy."  [Ref.  11]  The  Trusted  Network 
Interpretation  (TNI),  commonly  referred  to  as  the  Red  Book,  provides  an  interpretation  of  the  TCSEC 
for  networks.  The  Orange  and  Red  Books  establish  ratings  that  span  four  hierarchical  divisions:  D,  C, 
B,  and  A,  in  ascending  order  of  increasing  provisions  of  security.  Each  division  includes  one  or  more 
numerical  ratings,  numbered  from  1  to  3,  which  provide  a  finer-granularity  rating.  Stronger  ratings 
correlate  with  higher  numbers.  Thus  evaluated  .sy.stcms  are  as.signed  a  digraph,  such  as  C2  or  Al,  that 


places  the  system  in  a  class  in  a  division.  Currently,  the  following  classes  exist,  in  ascending  order:  Cl, 
C2,  Bl,  B2,  B3,  and  Al.  [Ref.  13]  Summary  criteria  for  the  various  classes,  reproduced  from 
the  Orange  Book,  can  be  found  in  Appendix  A. 

1.  Applicable  Navy  Instructions 

When  considering  shipboard  non-lactical  local  area  networks,  there  are  two  distinct  issues 
that  prevail  [Ref.  14): 

•  LANs  which  handle  personal  information  must  provide  in  accordance  with  the  Privacy  Act  of 
1974  (5  U.S.C.  552a)  and  the  Computer  Security  Act  of  1987  (Public  Law  100-235).  Any 
shipboard  LAN  that  will  incorporate  office  automation  will  fall  into  this  category. 

•  LANs  which  handle  classified  material  must  provide  securit_\  protection  in  accordance  with 
Executive  Order  12356  (National  Security  Information).  Any  shipboard  LAN  which  integrates  the 
ship’s  message  center  to  distribute  CONFIDENTIAL,  SECRET,  or  TOP  SECRET  message 
traffic  with  a  office  automation  system  will  fall  into  this  category. 

The  purpo.se  of  this  thesis  is  to  focus  on  the  latter  of  the  two  issues;  however,  a  brief 
discussion  of  the  personal  information  issue  is  considered  appropriate  because  methods  of  risk 
assessment  may  overlap  or  provide  mutual  support. 

a.  Safeguarding  Personal  Information  in  Automatic  Data  Processing  Systems 

SECNAVINST  5239.1  (Safeguarding  Personal  Information  in  Automatic  Data 
Processing  Systems)  is  the  Nasy’s  implementation  instruction  for  the  Privacy  Act  of  1974.  This 
instruction  addresses  personal  information  privacy  and  docs  not  pertain  to  classified  data.  Two 
enclosures  to  the  instruction  are  utili/.cd  to  establish  a  risk  asse.ssmcnt  approach  which  weighs  the 
likelihood  of  a  .security  breach,  the  damage  that  would  occur,  and  the  cost  of  prevention.  Because  of  the 
assessment  approach  taken,  the  instruction  should  not  be  considered  a  .set  of  firm  requirements  that  are 
mandatory  under  all  circum.stanccs.  The  document  suggc,sts  that  a  mixture  of  technical  and  physical 
safeguards  with  strict  administrative  controls  may  be  more  cost  effective  than  high-cost  technical 
solutions.  [Ref.  14:  p.  11] 


b.  Automatic  Data  Processing  Security  Program 

OPNAVINST  5239.1A  (Department  of  the  Navy  Automatic  Data  Processing  Security 
Program),  implements  DoD  Directive  5215.1  (Computer  Security  Evaluation  Center)  within  the 
Department  of  the  Na\y  and  integrates  the  directive  into  the  Navy’s  ADP  security  program. 
OPNAVINST  5239. lA  covers  both  personal  security  and  classified  data  security  issues.  It  divides  data 
into  three  protection  levels: 

•  Level  1:  Classified  data 

•  Level  11;  Unclassified  data  requiring  special  protection,  such  as  Privacy  Act  information 

•  Level  Ill:  Other  unclassified  data 

Similar  to  SECNAVINST  5239.1,  OPNAVINST  52.39.1A  is  based  upon  risk 
assessment  procedures  intended  to  balance  the  threat,  the  possible  damage,  and  the  cost  of 
countermeasures  in  a  cost  effective  manner.  Certain  minimal  mandatory  requirements  are  cited; 
however,  these  are  primarily  regarding  environmental/physical  security  and  contingency  planning  as 
opposed  to  technological  issues.  Additionally  the  instruction  establishes  the  definition  of  the  Designated 
Approving  Authority  (DAA)  for  ADP  accreditation.  For  most  shipboard  LANs  this  will  be  the 
Commanding  Officer,  however  if  the  LAN  is  operated  in  the  Multilevel  Security  mode,  the  authority  to 
accredit  the  system  rests  with  Commander.  Naval  Data  Automation  Command  (COMNAVDAC). 
Computer  systems  may  operate  for  a  limited  time  under  an  Interim  Authority  to  Operate,  which  is 
issued  by  the  DAA.  |Ref.  14:  p.  13) 

c.  Navy  Implementation  of  National  Policy  on  the  Control  of  Compromising  Emanations 

(TEMPEST) 

OPNAV'INST  C5510.93D  is  a  CONFIDENTIAL  instruction  that  provides  policy  for 
compliance  with  TEMPEST  requirements.  OPNAV  NOTICE  C5510  revises  the  OPNAV  instruction 
implementing  a  revised  national  policy  on  compromising  emanations.  This  notice  clarifies,  revises,  and 
in  some  cases  liberalizes  previous  requirements  for  full  TEMPEST  certification.  [Ref.  14:  pp.  12  to  13] 


This  technical  guidance  and  requirements  are  nut  the  focus  of  this  thesis  and  uill  not  be  pursued  further. 
The  author  believes  the  advent  of  fiber  and  use  of  fiber  optics  with  LANs  essentially  makes  TEMPEST 
requirements  relatively  simple  to  fulfill, 

2.  National  Computer  Security  Center’s  Standards 

In  addition  to  the  DoD  standards  previously  described  (Red  and  Orange  Books),  the 
National  Computer  Security  Center  (NCSC)  has  published  a  set  of  technical  guidelines  to  help  industry 
develop  certifiable  systems  and  enhance  the  NCSC-contractor  relationship  in  the  product  evaluation 
phase.  The  guidelines  promulgate  testing  standards  to  terminology  that  will  be  used.  A  complete 
description  of  these  various  standards  may  be  found  in  |Rcf.  14).  A  list  of  standards  is  provided  below; 

•  CSC-STD-003-85:  Computer  Security  Requirements 

•  CSC-STD-004-S5:  Technical  Rationale  Behind  CSC-.STD-()()3-8.5 

•  CSC-STD-(K)2-85;  DoD  Password  Management  (iuidc 

•  NCSC-TG-OOl:  Audit  in  Trusted  Sy.stems 

•  NCSC-TG-0fl2:  Trusted  Product  Evaluation 

•  NCSC-TG-003:  Di.scrctionary  Access  Control 

•  NCSC-TG-004:  Glossary  of  Computer  Security  Terms 

•  NCSC-TG-008:  Trusted  Distribution 

•  NCSC-TG-009:  Computer  Security  Subsystem  Interpretation 

•  NCSC-TG-flll:  Trusted  Network  Interpretation  Environments  Guideline 

•  NCSC-TG-013:  Rating  Maintenance  Phase 

•  NCSC-TG-019:  Trusted  Product  E%'aluation  Ouc.siionnaire 

The  above  guidelines  are  more  pertinent  to  the  computer,  .software,  and  network 
development  communities  than  to  the  user  community.  However,  the  documents  are  of  interest  to  the 
user  community  from  the  standpoint  of  supporting  a  well  informed  decision  regarding  the  acceptance 
of  a  network  for  a  particular  .set  of  shipboard  applications.  |Ref.  14:  p.  13) 


24 


111.  NAVAL  TELECO.MMIJNICATION.S 


The  Naval  Telecommunications  System  (NTS)  embraces  all  naval  telecommunications  operations 
that  provide  for  the  exchange  information  among  naval  forces  at  sea,  in  the  air,  and  ashore 
[Ref.  15). 


A.  BACKGROUND 

The  NTS  system  is  designed  to  get  necessary  communications  to  the  fleet.  Using  the  Defense 
Communications  System  as  a  backbone,  the  Naw  has  designed  ashore  and  afloat  automated  systems  to 
process  narrative  and  data  pattern  mcssagc.s.  [Ref.  16] 

1.  Ashore  Systems 

Shore  communications  stations  arc  the  backbone  of  the  NTS.  The  Naval  Communications 
Master  Stations  (NAVCAMS)  and  the  Na\al  Communications  Station  (NAVCOMMSTA)  provide  the 
conduit  for  communications  between  shore  commands  and  the  fleet.  A  summary  from  NTP-4C  [Ref. 
16:  pp.  2-1  to  2-5)  of  major  elements  of  the  .shore  site  of  NTS,  pertinent  to  this  thesi.s,  are  provided 
below; 


•  Automatic  Digital  Network  (AUTODIN)-  AUTODIN  is  a  world-wide  Department  of  Defense 
computerized  system  which  provides  automatic  switching  of  message  traffic  providing  significantly 
fast  service  to  ashore  locations.  The  system  transmits  both  narrative  and  data  pattern  (either  card 
or  magnetic  tape)  messages.  Autodin  provides  five  modes  of  operation  that  provide  for  the 
variation  in  speed  from  100. 

•  words-per-minute  duplex  teletypewriter  to  2400  baud  terminals. 

•  Naval  Communications  Processing  and  Routing  System  (NAVCOMPARS)-  NAVCOMPARS  is 
the  automated  communications  system  which  .serves  as  the  interface  with  AUTODIN  or  other 
networks  ashore  and  operational  fleet  units.  The  system  provides  fleet  support  through  broadcast 
management,  CUDIXS  or  full  period  terminations  and  primary  ship/shore  circuits.  There  are  five 
NAVCOMPAR  sites,  one  at  each  of  the  four  NAVCAMS  plus  one  at  NAVCOMSTA  Stockton, 
California. 

•  Local  Digital  Me.ssagc  Exchange  (LDMX)-  The  LDMX  proxide.s  automatic  message  routing  and 
reformatting  for  ashore  Na\y  commands.  It  .sati.sfics  the  Defense  Communication  Agency  (DCA) 
criteria  for  AUTODIN  accc.ss  and  permits  entry  of  traffic  through  optical  character  recognition 


equipment  (OCRE).  The  system  directly  distributes  incoming  messages  to  and  serves  as  the  file 
and  retrieval  location  for  remote  subscribers. 

•  Standard  Remote  Terminal  (SRT)/Reriiote  Information  Exchange  Terminal  (RIXT)-  SRT /RIXT 
is  an  input/output  terminal  which  allows  remote  users  to  acce.ss  AU  fODlN. 

•  Common  User  Digital  Information  Exchange  System  (CUDIXS)-  The  CUDIXS  sy.stem  could  be 
classified  in  ashore  and  afloat  systems,  but  its  primary  components  are  located  at  the  five 
NAVCOMPARS  sites.  This  system  provides  a  2400  baud  satellite  link  and  full  duplex  interface 
for  the  receipt  and  transmi.ssion  of  narrative  message  traffic  between  NAVCOMPARS  and  the 
ships  equipped  with  afloat  automated  .sy.stems. 

2.  Afloat  Systems 

The  heart  of  the  Navw  afloat  communication  .system  is  the  Naval  Modular  Automated 
Communication  System  (NAVMACS).  The  sy.stem  is  de.signed  to  increase  the  speed,  efficiency  and 
capacity  of  the  na\dl  afloat  and  ashore  communications  operations.  The  NAVMACS  modular  concept 
allows  the  system  to  be  configured  to  the  particular  ship  class.  Each  NAV'MACS  system  includes  a 
unique  device  for  the  composition  or  entry  of  outgoing  messages.  For  example,  a  message  entry  in 
NAVMACS  V2  requires  a  paper  tape  copy  of  the  message.  Each  ship  has  a  specific  type  of  output 
device  for  delivery  of  incoming  addressed  messages.  On  NAVMACS  V2/V3  ships,  a  reproduced  copy 
of  a  message  is  hand  delivered  to  the  reader.  However,  NAVMACS  V5  provides  on-line  remote 
distribution  for  addressed  messages  which  can  be  viewed  on  a  Keyboard  Video  Display  Terminal 
(KVDT)  screen  and/or  printed  on  a  remote  printer.  |Rcf.  17|  With  emphasis  on  the  types  of 
message  entrv  or  delivery  devices  provided  by  each  sy.stem,  the  various  hardware/software  configurations 
for  NAVMACS  equipped  ships  are  described  below: 

•  NAVMACS  (V)l.  This  single  AN/UYK-20  minicomputer-based  system  is  used  on  small  ships 
with  minimal  communication  requirements.  The  NAVMACS  (V)l  system  can  simultaneously 
input  and  screen  me.ssage  traffic  from  four  fleet  broadcast  channels  and  interface  with  the 
CUDIXS  Link.  NAVMACS  (V)l  CUDIXS  Link  communication  is  limited  to  send-only  for 
message  traffic.  Message  entry  for  outgoing  traffic  is  via  paper  tape,  and  distribution  of  incoming 
addressed  messages  is  manual,  using  reproduced  copies.  Delivery  devices  are  four  75-baud 
teletype  page  printers.  Message  composition  is  accomplished  using  teletype  equipment  which 
produces  5-levcl  paper  tapes  of  outgoing  messages.  [Ref.  17] 

•  NAVMACS  V2.  A  single  AN/UYK-20  or  AN/UYK-44  minicomputer-based  system, 
NAVMACS  V2  is  installed  on  .small  ships  with  more  peripheral  equipment  than  NAVMACS  Vl. 
The  NAVMACS  V2  system  can  simultaneously  input  and  screen  me.ssage  traffic  from  four  fleet 
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broadcast  channels  and  the  CUDIXS  Link  -  CUDIXS  Link  communications  are  half  duplex, 
providing  the  input  and  output  of  message  traffic.  Message  entry  for  outgoing  traffic  is  via  paper 
tape,  and  distribution  of  addressed  incoming  messages  is  manual,  using  reproduced  copies. 
Delivery  devices  are  two  2400-baud  medium-speed  line  pointers.  Outgoing  message  composition 
can  be  provided  by  a  Message  Preparation  Device  (MPD),  if  installed.  The  output  of  the  MPD 
via  the  NAVMACS  program  is  a  5-level  paper  tape  of  the  message  and  a  printed  copy  of  the 
message.  If  no  MPDs  are  installed,  message  composition  is  accomplished  by  using  teletype 
equipment  which  produces  a  5-leve!  paper  tape  of  the  message.  Other  means  of  5-level  tape 
production  already  being  used  on  .some  ships  are  di-scussed  later.  [Ref.  17] 

•  NAVMACS  V3.  NAVMACS  V3  is  a  dual  AN/UYK-2()  minicomputer-based  sy.stem  for  large 
ships.  The  NAVMACS  V3  system  can  simultaneou.sly  input  and  screen  me.s.sage  traffic  from  four 
fleet  broadcast  channels,  four  Full-Period  Termination  (FPT)  channels,  and  the  CUDIXS  Link. 
CUDIXS  Link  communications  arc  half  duplex,  providing  the  input  and  output  of  message  traffic. 
The  FPT  circuits  are  full  duplex,  providing  simultaneous  input  and  output  of  message  traffic.  The 
primary  means  of  message  entry  for  outgoing  traffic  is  by  me.s.sage  comp{).sition  at  one  of  the 
on-line  KVDTs.  Once  the  message  is  compo.sed.  it  can  be  transmitted  \sithout  being  re-entered 
by  paper  tape.  Another  method  of  outgoing  me.ssage  entry  is  via  paper  tape.  The  message  is 
loaded  into  the  .system,  and  if  no  format  errors  are  detected.the  me.ssage  is  output  on  the  desired 
circuit.  Distribution  of  incoming  addres.sed  me.ssages  is  manual,  using  reproduced  copies. 
Delivery  devices  are  two  24()0-baud  medium-.speed  line  printeis.  IRef.  17] 

•  NAVM.ACS  V5/V5A.  Up  to  three  AN/UYK-20A  or  AN/UYK-44  minicomputers  are  used  in 
this  system  for  very  large  ships  with  the  greate.st  communication  requirements.  The  NAV'MaCS 
V5/V5A  system  can  simultaneously  input  and  .screen  message  traffic  from  multiple  channels  of 
fleet  broadcast,  FPT,  remote  dcvice.s,  and  remote  .systems.  CUDIXS  Link  communications  are 
half  duplex,  providing  the  input  and  output  of  message  traffic.  The  FPT  circuits  arc  full  duplex, 
providing  the  simultaneous  input  and  output  of  message  traffic.  The  primary  means  of  message 
entry  for  outgoing  traffic  is  message  composition  at  one  of  the  on-line  KVDTs.  Once  the  message 
is  composed,  it  can  be  transmitted  without  being  re-entered  by  paper  tape.  A  second  method  of 
outgoing  message  entry  is  via  paper  tape.  .A  third  method  of  outgoing  message  entry  is  from  a 
remote  system  such  as  the  Personal  Computer  Remote  System  (PCRS)  or  the  Naval  Intelligence 
Processing  Sy.stem  (NIPS).  If  no  format  errors  are  detected,  the  me.s.sage  is  output  on  the  desired 
circuit.  Distribution  of  incoming  addressed  messages  is  automatic  and  ci)ntrolled  by  a  data  base 
maintained  by  NAVMACS  operators.  On  ship  dcliscry  devices  include  medium-speed  line 
printers,  KVDTs,  paper  tape  punches,  and  remote  .systems.  [Ref.  17| 


The  .NAV.MACS  systems  have  not  kept  pace  with  the  technology  and  proliferation  of  PCs 
and  word  processing  .software  during  the  i980'.s.  Nax'y  personnel,  now  more  computer  literate,  find  the 
message  preparation  capabilities  in  NAVMACS  limiting  and  le.ss  flexible  than  commercial  tc.xt  editors; 
consequently,  many  ships  have  purchased  PCs  and  .software  for  me.s.sage  composition  and  editing.  To 
proside  the  media  for  outgoing  message  entry  for  the  NAVMACS  .sy.stems,  ships  have  also  purchased 
paper  tape  reader/punches  to  provide  paper  tapes.  E.xpensivc  message  preparation  terminals,  with  very 
limited  text  editing  capability,  using  the  .MPDs  and  KVDTs  are  therefore  ignored.  [Ref.  17] 


B. 


SYNCROTECH  SOFTWARE  CORPORATION  INVESTICATION 


On  April  26.  IW]  S\ntrolcth  Sofluarc  Corporation  proxidcd  results  to  NCHTS  arncerning  a  study 
of  options  for  connecting  the  Nasal  Modular  Automated  Communications  Sy.stems  (NAV.M.ACS)  and 
personal  computer  (PC)-based  Local  Area  Networks  (LAN)  aboard  Navy  ships.  The  report 
demonstrated  the  feasibility  of  interfacing  all  systems  with  GateGuard.  GateGuard  is  a  PC-based, 
software-controlled  sy.stem  which  is  already  used  as  a  shore-based  communications  link  between 
Automatic  Digital  Network  (AUTODIN)  Subscriber  Terminals  (AST)  and  Office  Automation  Systems 
(OAS)  via  a  LAN.  GateGuard  functions  as  a  gateway  to  AUTODIN  and  provides  the  protection  of  a 
security  guard  device  separating  AUTODIN  and  the  OAS.  The  .sy.stem’s  name  is  derived  from  these 
basic  functions.  [Ref.  17) 

1.  Syncrotech  Corponition  .Assumptions 

Syncrolech  based  their  inve.stigation  on  .several  assumptions  which  are  prov  ided  below  from 

IRef.  17): 

1.  If  required  the  NAN’MACS  lamily  of  software  canild  be  modified.  However,  the  amount  of  coding 
needed  to  implement  a  new  Inpul/Oulput  (I/O)  driver  to  handle  a  PC/GaleGuard  interface 
required  investigation.  Any  additional  code  would  reduce  the  already  low  amount  of  dynamic 
memory  used  to  temporarily  store  incoming  messages.  This  is  most  critical  in  NAVMACS  V2,  which 
has  no  long-term  storage.  NAVMACS  VI  was  not  a  candidate  for  the  PC/GateGuard  interface. 

2.  For  security  reasons,  the  GateGuard  terminal  would  be  co-located  with  the  NAV.MACS  V2/V3 
systems,  since  NAVMACS  V2  provides  no  security  control  for  delivery  devices,  and  NAVMACS  V'3 
only  provides  security  control  for  transmit  circuits.  GateGuard  would  provide  the  security  protection 
required  for  NAVMACS  V2/V3  remote  distribution.  NAVMACS  V5  can  control  the  level  of 
security  for  any  remote  system  or  device. 

3.  The  current  screening/control  functions  (e.  g  -,  Command  Guard  Li.st  (CGL).  Local  Routing  List 
(LRL),  or  all  NAVMACS  V5  .screening)  would  remain  in  the  respective  NAVMACS  programs,  and 
GateGuard  would  only  be  used  to  augment  these  functions  at  an  office  level.  The  final  control  of 
when  and  how  a  me,ssage  is  transmitted  on  a  specifie  circuit  would  also  still  remain  in  the 
NAVMACS  program. 
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2.  Syncrotech  Corporation  Projxised  Solutions 

In  Syncrolcch's  report  the  final  proposed  solutions  fell  into  three  categories;  a  solution  for 
NAVMACS  V5,  a  solution  for  NAVMACS  V2  and  V3,  and  a  long  term  solution  for  the  entire 
NAVMACS  modular  family.  The  proposed  solutions,  from  |Rcf.  17J  are  summarized  below. 

1.  NAVMACS  V5/V5A  -  NAVMACS  \'5/V5A  currently  supports  a  remote  system  interface  which 
provides  a  path  for  outgoing  message  entry  and  remote  distribution.  The  Generic  Interface  Design 
Specification  (IDS)  for  NAVMACS  V5/V5.A  provides  the  information  necessary  to  pass  messages 
to  and  from  .NAVMACS  V5/V5A.  U.sing  this  interface,  NAVMACS  V5/V.5A  could  be  connected 
to  GateGuard.  NAVMACS  V5/V5A  would  interface  with  (JateGuard  via  a  Bus  Interface  Unit  (BIU) 
while  the  ship  is  underway.  While  in  port,  the  Gateguard  could  connect  with  the  local  NTCC,  via 
secure  telephone  communication.s,  for  over  the  counter  me.s.sage  traffic  delivery.  The  various  interface 
connections  arc  made  po.ssiblc  by  the  BIU,  which  provides  the  required  interface  level  conversions 
and  handles  the  interface  protocol  nece.ssary  to  pass  message  data.  The  softvv, ire-controlled  interface 
protocol  in  the  BIU  would  have  to  be  changed  to  comnumicale  u.sing  NA  v'MACS  V5/V5A  generic 
interface  protocol  while  the  ship  is  underway.  While  the  ship  is  in  port,  the  BIU  could  use  the 
existing  AST  protocol  to  interface  with  the  shore.  The  .software  in  the  BIU  which  communicates  with 
GateGuard  would  remain  unchanged  in  either  case.  Changes  to  the  NAVM.ACS  V5/V5A  remote 
system  interface  were  analyzed  but  were  not  propo.sed  because  these  flex  channels  are  now  used  by 
several  other  systems.  Any  software  to  handle  the  current  BIU  protocol  would  require  additional 
changes  to  the  NAVMACS  V5  operating  .system,  as  well  as  the  addition  of  a  new  remote  .sy.stcm 
software  control  module. 

2.  NAVMACS  V2/V3.  As  designed,  NAVMACS  V2/V3  .software  does  not  provide  a  remote 
interface  for  message  entry  and  delivery.  However,  NAVMACS  V2/V3  does  provide  an  International 
Telegraph  Alphabet  #2  (lTA-2)  Baudot  interface  which  inputs  data  from  and  outputs  data  to  a 
75-baud  lTA-2  Baudot  device,  normally  a  paper  tape  rcadcr/punch.  Acce.s.s  to  this  I/O  channel  is 
provided  via  a  secure  patch  panel.  The  program  controlled  baud  rate  for  this  channel  is  currently  set 
at  the  lowest  rate  on  the  AN/UYK-20  I/O  card.  The  rate  may  be  changed  by  restrapping  the  1/0 
card;  the  software  need  not  be  modified.  While  the  ship  is  underway,  a  BIU  could  be  connected  to 
this  channel,  and  the  required  interface  protocol  software  could  be  downloaded.  NAVMACS  V2/V3 
would  then  be  interfaced  with  GatcGuard  as  shown  in  Figure  3.  Mc.ssage  entry  for  NAV.MACS  V2 
transmission  on  the  CUDIXS  Link  would  be  handled  like  the  current  method.  The  NAVMACS 
operator  would  enter  TRA  TR2,  and  the  (iate(«uard  operator  would  then  initiate  the  me,ssage 
transfer  to  NAVMACS  via  the  BIU.  Mc.ssage  entry  from  NAVMACS  V3  would  be  accomplished 
by  using  the  LOD  MSG  TR2  RELAY  command  from  any  KVDT.  Message  distribution  to 
GateGuard  could  be  accomplished  by  modifying  the  NAVM.AC\S  V2/V3  .software  to  send  all 
addressed  mc.ssages  to  both  PRl  and  TP2.  .Message  dLstribution  m.iy  also  be  accomplished  by  having 
the  shore  station  add  a  Plain  Language  Addre.ss  (PLA)  to  the  NAVMACS  Originator  Screening  List 
(OSL)  for  all  fleet  broadcast  and  CUDIXS  mcssage.s.  The  NAVMACS  \’2/V3  operator  can  then 
take  TPl  down,  which  altroutes  the  mc.ssages  to  TP2  (GatcCJuard)  for  distribution  to  a  LAN.  The 
GateGuard  terminal  should  be  located  inside  the  Main  Communication  Center  (MAIN  COMM), 
as,  NAVMACS  cannot  control  the  security  level  for  messages  sent  to  TP2.  Responsibility  for  primary 
delivery  of  addressed  messages  would  still  remain  with  the  line  printer  connected  to  the  NAVMACS 
V2/V3  system.  While  the  ship  is  in  port,  NAVM.ACS  V2/V3  could  receive  over-the-counter  service 
via  a  shore  AST  connection.  The  BIU  would  then  be  downloaded  with  the  AST  interface  protocol 
software. 
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3.  NAV'MACS  V2/V3/V5/V5A  Uni\crsal  Serial  Inlcrfacc.  A  PC  with  the  required  serial  interface 
boards  can  be  connected  to  any  NAVMACS  system.  Software  capable  of  handling  all  the  required 
functions  could  then  be  downloaded  and  run  under  Windows.  Because  GatcGuard  does  not  currently 
provide  these  features,  the  PC  program  would  ha\c  to  be  developed  using  commercial  off-the-shelf 
software  when  possible.  The  NAVMACS  Universal  Serial  Interface  (NUSl)  concept  would  at  a 
minimum  provide  windows  for  the  Control  Teletype  (CTTY),  KVDT,  paper  tape  reader/punch, 
diskette  message  entry /storage  interface,  LAN,  shore  AUTODIN  connection,  and  remote  system 
interface.  Each  serial  interface  connection  would  be  assigned  a  window  for  monitoring  and  control. 
Access  to  each  window  would  be  provided  by  the  host  PC.  The  functions  provided  by  each  window 
would  be  limited  to  the  existing  services  that  each  interface  currently  provides  (e.  g  the  CTTY 
window  would  be  used  for  NAVMACS  V2  command  entry/system  response).  One  major  advantage 
to  this  proposed  solution  is  that  it  overcomes  the  message  entry  problem  which  occurs  when  an 
operator  enters  TRA  TR2  on  the  CTTY  or  LOD  MSG  TR2  RELAY  from  a  NAVMACS  V3 
KVDT.  When  the  operator  enters  TR.A  TR2  in  the  CTTY  window,  the  program  could  initiate  the 
input  message  transfer  immediately  because  it  also  controls  the  message  entry  to/from  NAVMACS 
via  the  TP/TR2  1/0  port.  The  same  applies  to  the  NAVMACS  V3  system  through  the  use  of  a 
KVDT  window. 


NAVMACS 

V2/V3 

TP/TP2  INTERFACE 


Figure  3  NAVMACS  V2/V3  and  Gaicguard  inlcrfacc 
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3.  Sjucrotecli  Corporati<»n  Coneluiiions 

The  Swcrotech  report  final  conclusions  slated  that  GatcGuard  can  be  connected  to  any 
NAVMACS  system  provided  that  the  BIU  interface  protocol  can  be  changed  to  accommodate  each 
system.  Additionally,  changes  to  the  NAVMACS  interface  handlers  to  emulate  the  required  transfer 
protocol  for  the  BIU  interface  are  restricted  by  memory  limitations.  N.AX'MACS  \’2/\’3  software  must 
be  changed  to  provide  distribution  to  a  device  (1/0  channel)  other  than  PRl  and  PR2  unless  the 
concepts  outlined  by  Syncroiech  arc  utilized.  |Rcf.  17| 

C.  SHORE  COMMAND  l.NTERF.ACE 

Naval  Communication>  Detachment.  Cheltenh.im.  .Maryland,  the  Naval  command  rc.sponsible  for 
maintaining  the  N.AVM.ACS  family  .software,  currently  has  a  GaleGuard  computer  linked  to  their 
servicing  LD.MX  using  a  Bit  Interface  Card  (BIC)  to  replace  a  BIU.  In  other  words  they  arc  u.sing  an 
inboard  circuit  board  to  replace  an  outboard  box.  The  protocol  used  between  LDMX  and  GatcGuard 
is  not  supported  by  NAVMACS.  Software  in  the  BIC  will  have  to  be  modified  to  support  N.AVM.ACS 
V5  remote  terminal  protocol.  To  date,  no  further  progress  has  been  made  in  connecting  GatcGuard  to 
NAV.MACS.  (Ref.  ISj 

D.  N.AVM.ACS  II 

Director.  Space  and  Electronic  Warfare  (OP-Oy4).  is  the  principal  advi.sor  to  the  Chief  of  Naval 
Operations  (CNO)  concerning  command  and  control  matters,  and  is  rcspon.siblc  for  ensuring  optimum 
use  of  Navy  Information  systems  (Ref.  IVj.  OP-IW4  is  currently  strongly  pursuing  a  program  to 
replace  the  NAVM.ACS  variants  with  N.AV.M.ACS  II.  H.trdwarc  for  this  .system  would  be  acquired  from 
a  Command  and  Control  Work.sialion.  Initially  this  uses  the  De.sk  Top  Computer  Contract  2  (DTC-2). 
Initial  dc.sign  u.scs  a  SUN  workstation  with  VME  bus  SPARC  technology.  The  hardw^arc  would  l>e 
designed  and  implemented  to  accommodate  upgrades  every  eighteen  to  twenty-four  months.  Software 
utilizes  the  UNIX  operating  system,  and  application  programs  will  be  wTitten  in  C  and  Ada.  This  sv'stcm 
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has  an  ETHERNET  interface,  so  connectivity  to  remote  terminals  on  a  LAN  is  planned.  However,  the 
driving  force  to  replace  NAVMACS  variants  is  to  replace  the  maintenance-expensive  U  YK-20’s  and  44s 
and  to  obtain  a  system  that  can  support  higher  speed  ship-shore  links.  An  overview  of  NAVMACS  II 
can  be  seen  in  Figure  4.  The  schedule  for  deployment  of  this  prototype  system  is  ambitious  and 
scheduled  for  April  of  1992.  Plans  are  to  deploy  the  system  battlegroup  by  battlegroup,  which  means 
literally  dismantling  the  system  on  an  individual  ship  within  one  battlegroup  and  installing  it  on  another 
ship  in  a  different  battlegroup.  Although  the  NAVMACS  11  specifically  intends  to  interface  with  a  LAN, 
little  attention  has  been  given  to  security  issues.  |Rcf.  20) 
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•  REMOVE  UNNECESSARY  EQUIPMENT/REOUCE  ONBOARD 
EQUIPMENT  COUNT 


•  REDUCE  OPERATOR  AND  MAINTAINER  WORKLOADS 

•  BUILDS  ON  EXISTING  FUNCTIONALITY 


Figure  4  NAVMACS  II  overview 
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E.  ASSESSMENT 


As  discussed  in  Chapter  I,  any  viable  shipboard  LAN  must  be  capable  of  integrating  the  ship’s 
message  center.  The  first  step  to  accomplish  this  was  taken  by  having  Syncrotech  research  the  feasibility 
of  connecting  NAVMACS  with  a  GateGuard  computer.  Unfortunately  no  further  progress  has  been 
made  due  to  the  desire  to  acquire  the  NAVMACS  11  variant  and,  in  the  author’s  opinion,  the  lack  of 
a  NaNy  Command  entity  pushing  to  get  the  task  accomplished.  Regardless  of  the  NAVMACS  variant, 
the  issue  of  routing  various  classifications  of  messages  on  a  shipboard  LAN  has  not  been  addressed.  The 
state  of  world  affairs  and  the  subsequent  declining  US  Defense  budget  may  delay  the  acquLsition  of 
NAVMACS  II.  The  recommendation  of  Synciotech  to  modiI_\  the  NA\'MACS  V2  and  V3  operating 
system  should  be  pursued  to  fuither  the  piogie.ss  towards  a  miiltile\el  secure  shipboard  LAN.  The 
Syncrotech  focus  on  the  NAV'MACS  V.5  system  akso  confirms  the  author's  opinion  that  onlj  large  ships, 
such  as  aircraft  carriers  and  hea\y  amphibious  assault  ships  will  benefit  from  any  further  progress.  NCTS 
provided  Syncrotech  with  a  listing  of  Afloat  Automated  Telecommunications  systems  for  which  they 
were  responsible  fo’’  maintaining  the  appropriate  software  operating  programs.  The  commands  included 
Coast  Guard  units  as  well  as  several  Marine  Corps  commands.  The  list  was  qualified  as  being  subject 
to  change  due  to  \arious  fleet  upgrades  and  ship  decommissioning.  Regardless,  the  figures  are  apparent 
that  the  primary  NAVMACS  variant  in  use  is  the  NAVMACS  V2.  Of  the  402  commands  listed,  the 
breakdown  of  NAVMACS  variants  is  as  follows;  NAVMACS  V5/V.5A:  28,  NAVMACS  V3:  69, 
NAVMACS  V2;  266,  NAVMACS  VI;  50.  Admittedly,  larger  commands  with  NAVMACS  V5  process 
more  message  traffic;  howeser,  it  may  be  prudent  to  pursue  a  multilevel  .secure  LAN  on  a  NAVMACS 
V2  or  V3  ship  where  quality  control  could  be  more  easily  accomplished  and  le.ssons  learned  provided 
to  benefit  implementation  on  larger  ships.  Simply  .staled,  it  would  be  easier  to  evaluate  a  multilevel 
secure  LAN  an  a  Guided  Missile  Cruiser  with  fewer  nodes  (easier  initial  physical  security  to  monitor) 
and  less  classified  message  traffic. 
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IV.  DEFENSE  MESSAGE  SYSTEM  INITIATIVES 


The  largci  architecture  of  the  Defense  Message  System  (DMS)  is  to  provide  electronic  delivery 
of  messages  between  organizations  and  individuals  in  the  DoD.  AUTODIN  currently  provides  message 
service  between  organizational  elements  while  the  DDN  E-Mail  provides  message  service  between 
individuals.  Although  both  system  provide  messaging  services  to  DoD  users,  they  are  currently  not 
interoperable.  DMS  consists  of  hardware,  software,  procedures,  facilities,  and  personnel  involved  in 
transferring  messages  from  writer  to  reader,  except  for  the  transmission  systems  providing  connectivity, 
such  as  the  Defense  Data  Network  (DDN)  and  base  level  transmission  faciliiics.  The  DMS  target 
architecture  will  attempt  to  make  AUTODIN  and  DDN  E-Mail  inlci operable,  therefore  r  baseline  was 
established  consisting  of  AUTODIN,  its  bascicsel  support  Telecommunications  Centers  (TCCs),  and 
E-Mail  on  the  DDN,  as  they  existed  in  September  of  19<S9.  This  baseline,  frozen  in  time  for  comparison 
purposes,  serves  as  the  reference  again.st  which  the  future  performance,  costs,  and  manpower  incurred 
during  the  evolution  of  the  target  architecture  will  be  measured  and  compared.  |Ref.  21 1 

DMS  is  not  and  will  not  be  a  network  or  a  .single  supplier  sersicc.  It  is  intended  and  foreseen  th-tt 
DMS  will  be  a  multi-vendored  combination  of  user-owned  and  managed  equipment  in  combinition  with 
user-leased  services  connected  to  DCS-owned  and  managed  equipment.  Interoperability  and 
standardization  of  these  various  equipments  and  services  will  be  achieved  by  linking  them  together  with 
a  common  set  of  messaging  (X.400)  and  directory  (X.500)  protocols.  [Ref.  21:  p.  1-2] 

A.  BACKGROUND 

Previous  efiorts  to  modernize  the  DoD’s  messaging  capabilities  were  terminated  in  January  of 
1988  by  the  Assistant  Secretary  of  Defense  Cr.  nand.  Control,  Communications  and  Intelligence  (ASD 
C3Ij  due  to  blunders.  A  multi-service  and  Agency  Dcfen.se  Mc.ssage  System  Working  Group  (DMSWG) 
was  then  established  to  a.ssess  the  DoD’s  me.ssaging  .systems  future.  The  goal  was  to  improve  the  current 
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system’s  functionality,  survivability,  and  security  while  concurrently  reducing  costs,  staffing,  and 
maintenance  services.  |Ref.  21;  p.  1-1) 

Through  1988,  a  recommended  architecture  and  the  phases  for  transi'ioning  from  the  ba.-.eline 
to  the  target  sy.stem  were  developed  and  approved.  In  August  of  19S  he  Under  Secretary  for 
Acquisition  issued  DMS  progiam  guidance  assigning  the  Defense  Com  lions  Agency  (DCA)  the 

overall  coordination  responsibilities  for  the  DMS  program.  guidance  provided  a  phased 
implementation  strategy,  a  test  and  evaluation  strategy  aiong  with  conceptual  approval  of  the  target 
architecture.  On  November  2,  1989,  ASD  C3I  issued  a  policy  for  transition  to  the  DMS  target 
architecture,  mandating  all  serviccs/agcncies  to  develop  and  maintain  their  own  DMS  transition  plans 
which  detail  the  evolution  of  the  base  level  and  regional  messaging  facilities  to  the  DMS  target 
architecture.  [Ref.  21:  p.  1-1] 

B.  DEPARTMENT  OF  THE  NAVY  TRANSITION  PLAN 

The  Department  of  the  Navy  (DON)  implementation  of  the  DMS  will  be  evolutionary  and  is 
being  conducted  in  three  phases.  Phase  1.  1989-1994,  centers  on  the  automation  of  existing  TCC 
functions,  the  extension  of  me,ssdgc  .services  to  the  user,  and  migrating  AUTODIN  data  pattern  traffic 
to  the  DDN,  AUTODIN  and  DDN  E-Mail  will  continue  to  e.visi  as  .sepal ale  bul  inicroperable  systems 
at  the  end  of  Phase  1.  In  Pha.se  11,  199,S-20()(),  the  TCCs  will  begin  to  be  phased  out  and  the  X.4()()  and 
X.500  protocols  will  become  available.  Base  u.scr  desk-top  workstations,  connected  via  BITS,  will  provide 
base-wide  connectivity.  Planned  Message  Security  Protocol  (MSP)  components  will  be  embedded  in  the 
user  workstation  to  permit  secure  messaging  throughout  DoD.  Phase  Ill,  estimated  for  completion  by 
the  year  2008,  will  implement  the  final  DMS  target  architecture.  The  ultimate  goal  of  this  final  phase 
is  to  provide  end-to-end  Integrated  Services  Digital  Network  (ISDN)  connectivity.  [Ref.  22] 

Phase  I  implementation  is  currently  ongoing  in  a  strong  and  steady  manner.  This  phase  primarily 
involves  shore  commands  and  their  servicing  Navy  Telecommunications  Centers  (NTCCs). 


.3.^ 


1. 


Na\'j'  Telecommunications  Centers 


Presently,  NTCCs  provide  DON  users  with  access  to  AUTODIN  and  offer  over-the- 
counter  (OTC)  message  services.  Organizations  which  include  ships  in  port  and  Naval  shore  commands 
(defined  as  subscribers),  exchange  messages  with  their  servicing  NTCC  via  the  manual,  manpower 
intensiv'e,  laborious  OTC  procedure.  These  procedures  include  manual  distribution  decisions  on 
incoming  messages  as  well  as  paper  reproduction  and  manual  collation  of  multiple  page  messages.  The 
NTCC  is  said  to  either  guard  or  protect  for  the.se  subscribers.  The  term  "guard"  means  that  the  NTCC 
provides  internal  office  distribution  to  specified  subscribers.  The  term  "protect"  specifics  the  NTCC  to 
provide  onl\  a  set  number  of  copies  to  the  subscriber,  which  arranges  for  its  oun  internal  distribution. 
Currently  NTCC  .systems  include  LDMX,  SRT,  and  RlXT.s,  which  were  defined  and  de.scribed  in 
Chapter  III.  NAVCOMPARS,  also  de.scribed  in  Chapter  II,  provides  communication  links  between 
underway  ships  and  AUTODIN.  Although  outside  the  scope  of  DMS,  the  NAVCOMPARS  must  evolve 
to  interface  to  the  new  DMS  messaging  service.  (Ref.  22:  p.  E4] 

It  is  the  DMS  Phase  1  implementation  that  is  most  applicable  to  the  shipboard 
environment,  and  this  phase  where  technology  and  lessons  learned  can  be  utilized  in  developing  a 
shipboard  LAN  capable  of  fully  integrating  the  ship’s  communication  center.  Chapter  HI  discussed 
Syncrotech  Corporation’s  investigation  into  connecting  NAVMACS  to  CJateGuard.  The  author  has 
deducted  that  the  tasking  for  the  inve.stigation  v\as  prompted  by  the  DMS  Pha.se  I  implementation  at 
certain  NTCCs  and  shore  commands. 

With  the  goal  of  providing  writer-to-reader  me.ssaging,  the  implementation  of  the  DMS 
in  the  DON  will  eliminate  messages  using  paper  media  between  the  user  organization  and  the  NTCC. 
DMS  Phase  1  will  utilize  the  Nav'y  Standard  Teleprinter  Ashore  (NSTA)  to  satisfy  requirements  for  low- 
cost  message  terminals,  replacing  teletype.  Optical  Character  Readers  (OCRs),  and  punched  card/tape 
equipment.  The  NSTA  allows  a  Personal  Computer  Message  Terminal  (PCMT)  to  exchange  traffic  with 
the  NTCC  using  diskettes.  Although  the  exchange  of  diskettes  requires  couriers  (over-the-counter 
service),  the  implementation  eliminates  the  use  of  paper,  OCRs,  and  card  punches,  facilitating  easier 
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message  handling  at  the  NTCC.  The  use  of  GateGuard  provides  electrical  connectivity  to  the  NTCC 
(with  the  LDMX)  using  the  KERMIT  protocol.  As  described  in  Chapter  III,  GateGuard  is  linked  to  the 
user’s  organization  Office  Automation  System  (OAS).  GateGuard  ensures  that  traffic  electronically 
received  from  the  NTCC  does  not  exceed  the  classification  level  of  the  OAS.  The  implementation  of 
common  procedures  and  central  accountability  for  organizational  message  receipt  establishes  a 
certification  boundary  between  the  DON  and  the  DCA.  initially,  GateGuard  has  only  supported 
electrical  me.ssagc  transfer  from  the  NTCC  to  the  OAS.  When  approved  release  authentication 
technologies  or  procedures  are  implemented  on  the  OAS,  a  two  way  GateGuard  exchange  will  be 
allowed.  [Ref.  22:  pp.  3-2  to  3-3| 

Currently,  most  organizational  OASs  run  at  the  unclassified  level.  Higher  classified  LANs 
exist,  but  normally  run  on  a  system  high  level  concept,  which  was  discussed  in  Chapter  II.  Separate 
GateGuard  are  required  for  unclassified  messages  passed  to  the  OAS  and  for  classified  messages  printed 
or  written  to  diskette  for  manual  dissemination.  If  a  certified  multilevel  secure  LAN  exists,  only  one 
GateGuard  will  be  required.  The  Na\7  DMS  transition  plan  calls  for  pursuit  of  accreditation  for  a  single 
GateGuard  capable  of  segregating  messages  by  classification.  [Ref.  22:  pp.  3-3  to  3-4] 

The  Phase  I  plan  also  includes  the  implementation  of  a  Multilevel  Mail  Server  (MMS)  that 
will  provide  dedicated  and  dial-up  GateGuard  interfaces  to  u.ser  electronic  mail  bo.xes  at  the  NTCC.  The 
MMS  will  allow  the'  exchange  of  message  traffic  classified  up  to  SECRET.  Additionally,  a  network  of 
MMSs  is  being  planned  to  phase  out  the  u.se  of  AUTODIN.  The  MMS  network,  interconnecting  MMSs 
via  the  Defense  Integrated  Secure  Network  (DISNET),  will  handle  AUTODIN  message  traffic  between 
Naval  commands  served  by  the  MMS.  [Ref.  22:  p.  E6j 

MMS  will  be  discussed  in  greater  detail  below;  however  a  brief  overview  of  security 
services  from  [Ref.  22]  is  considered  appropriate  because  it  may  provide  some  points  for  comparison 
when  reviewing  shipboard  options. 
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2.  Securit}  Services  Provided 

Present  DON  NTCCs  systems  have  not  been  formally  evaluated  in  accordance  with  the 
DoD  directives  discussed  in  Chapter  II.  The  systems  are  certified  by  the  Naval  Telecommunications 
Integration  Center  (NAVTELSYSIC)  and  accredited  by  Commander,  Naval  Computer  and 
Telecommunications  Command.  Additional!),  all  NTCC  .systems  undergo  DCA  certification  before 
connecting  to  AUTODIN.  All  communication  links  to  the  AUTODIN  are  encrypted  using  the  KG 
family  of  encryption  devices.  The  DDN  is  currently  segregated  into  the  MILNET  for  unclassified  service 
and  the  three  other  networks  are  for  classified  material.  Each  classified  network  carries  only  one  security 
level,  SECRET  on  DISNET  1,  TOP  SECRET  on  DISNET  2,  and  TOP  SECRET/  SPECIAL 
COMPARTMENTED  INFORMATION  (SCI)  on  DISNET  3.  Intentions  are  to  merge  the  three 
separate  networks  into  one  network,  the  DISNET.  Phy.sically  unprotected  trunks  and  host  access  lines 
on  the  MILNET  are  being  link  encrypted  using  KG-84As.  A  Low-cost  Encryption  and  Authentication 
Device  (LEAD)  is  planned  to  provide  link  encryption  on  MILNET  terminals.  On  the  classified  systems, 
KG-84A  devices  are  u.sed  for  link  encrypti()n  of  physically  unprotected  trunks,  host  access  lines,  and 
terminal  access  lines.  BLACKER,  providing  end-to-end  link  encryption  is  beginning  to  be  implemented 
on  the  three  DISNETS.  [Ref.  22;  pp.  3-36  to  3-37| 

C.  MULTILEVEL  MAIL  SERVER 

The  objective  of  the  Multilevel  Mail  Server  (.MMS)  project  is  to  provide  the  capability  of 
electronically  exchanging  various  classified  organizational  messages  between  NTCCs  LDMX  and  its 
over-the-counter  subscribers.  This  will  be  accomplished  with  dial-up  interfaces  between  a  subscribers 
GateGuard  to  subscribers  mailboxes  within  the  MMS.  The  initial  MMS  will  be  installed  at  NTCC 
Cheltenham,  Maryland  to  aid  in  defining  configuration  requirements  and  operational  procedures  needed 
for  fielding  at  other  sites.  Specific  goals  for  the  MMS  project  include  |Rcf.  23): 

•  Provide  Gateguard  with  connectivity  to  the  TCC 

•  Provide  extended  storage  for  organizations  not  operating  on  a  24  hour  basis 


•  Provide  message  separation  by  classification 

•  Provide  low  cost  secure  dial-up  connectivity 

•  Eliminate  LDMX  port  availability  contention 

•  Eliminate  over-the-counter  processing  of  Unclassified  to  Secret  AUTODIN  messages 

•  Provide  the  connectivity  for  receipt  and  transmission  of  AUTODIN  messages  via  diskette  or  the 
subscriber  OAS. 

1.  MMS  (leneral  Operating  Oveniew 

The  LDMX  will  segregate  subscriber’s  message  traffic  by  classification  to  separate  circuits 
for  the  MMS.  Three  circuits  will  be  provided,  one  each  for  Unclassified.  Confidential,  and  Secret 
messages.  After  processing  the  messages  from  the  LDMX,  the  MMS  will  post  the  messages  to 
separately  segregated  subscriber  accounts  that  have  been  programmed  into  the  MMS  Alias  file.  The 
MMS  will  determine  the  correct  mailbox  account  for  each  message  received  by  reading  a  predefined 
and  pre-formatted  Routing  Indicator  (Rl)  from  the  established  format  line  and  field  of  the  message. 
[Ref.  23:  p.  2-3] 

Subscribers  will  access  the  MMS  from  their  installed  GateOuard  systems  and  Secure 
Telephone  Unit  111  (STU-llI)  using  the  public  telephone  net\sork.  When  sub.scribers  access  the  MMS, 
they  will  be  able  to  download  messages  waiting  for  them.  MMS  will  download  me.ssages  that  are 
classified  at  the  cla.ssification  level  that  was  acces.sed.  The  MMS  will  allow  subscribers  to  download 
messages  that  are  cla.ssified  at  lowvr  cla.ssification  ie\els  than  that  level  u.sed  to  acce.ss  the  MMS, 
provided  the  subscriber  had  previously  notified  the  NTCC  of  the  requirement  to  dow-nload  messages  of 
multiple  classifications  during  one  login  session.  Higher  classification  levels  than  the  one  that  is  used  to 
access  the  MMS  will  not  be  able  to  be  downloaded.  [Ref.  23:  p.  2-3] 

CL  The  MMS  Processor 

The  AT&T  3B2/600G  minicomputer  available  from  the  Standard  Multi-user  Small 
Computer  Requirements  Contract  (SMSCRC)  will  be  u.sed  as  the  MMS  processor.  The  computer  will 
operate  at  24  MHz  and  contain  a  minimum  of  32  MBvics  of  Random  Access  .Memor\  (RAM).  It  w'ill 


be  equipped  with  a  multi-processor  board  which  will  support  off-loading  man)  of  the  less  important 
system  functions  to  itself  thereby  prusiding  more  time  for  the  main  processor  to  perform  the  primary 
system  functions.  The  system  was  also  designed  to  accommodate  future  expansion  of  the  MMS 
requirements  through  system  upgrades.  (Ref.  23:  pp.  3-7  to  3-8] 
b.  MMS  Operating  System 

The  M.MS  procc.ssor  will  initially  run  release  3.2.3.30  of  the  UNIX  System  V/MLS 
operating  system  which  was  specifically  designed  for  the  3B2/600(j.  The  operating  sy.stem  is  designed 
to  meet  the  TCB  level  of  Bl,  however  it  is  not  yet  certified  by  NCSC.  The  operating  system’s 
predecessor  is  currently  certified  at  the  Bl  level,  and  because  the  new  version  is  simply  an  extension  of 
the  certified  release  it  is  expected  the  new  release  will  be  certified  prior  to  installation  at  Cheltenham. 
The  system  V/MLS  TCB  is  protected  from  modification  by  non-administrati\c  users  through  mandatory 
and  discretionary  access  control.  The  .system  w'ill  be  used  in  a  multi-user  mode.  (Ref.  23:  p.  3-11] 

2.  Selected  MMS  Detailed  Operating  Characteristics 

The  MMS  will  prosidc  on-line  access  for  the  electronic  exchange  of  AUTODIN  messages 
between  the  NTCCs  LDMX  and  a  subscriber’s  (latcOuard.  Two  way  transfer  of  me.ssages,  from  the 
LDMX  to  the  GateGuard,  and  from  the  GateGuard  to  the  LDMX  is  the  ultimate  goal.  The  MMS  is 
the  interface  between  the  two  systems  and  requires  the  capability  to  commiinicals  with  both,  while 
concurrently  .separating  messages  by  classification.  |Ref.  23:  p.  3-K)| 

The  M.MS  w'ill  utilize  V/MLS  Secure  Mail  Package  to  enable  the  system  to  work;  in  the 
author’s  opinion,  a  similar  package  will  be  an  integral  part  of  a  future  shipboard  MLS  LAN.  The  E-mail 
package  of  the  MMS  V/MLS  Operating  System  is  mandatory  and  must  be  included  in  the  final  Bl 
certification.  The  secure  mail  package  proxides  a  repository  for  messages  received  from  both  the  LDMX 
and  from  the  subscriber’s  GateGuard.  (Ref.  23:  p.  3-11] 

Each  subscriber  organization  will  have  mailbox  accounts  established  within  the  MMS  and 
individual  messages  will  be  po.sted  to  .separate  class-marked  mailboxes.  After  determining  appropriate 
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distribution  upon  receiving  the  message  from  the  LDMX  the  MMS  E-mail  system  will  append  an  E-mail 


header  to  the  message  and  post  it  to  the  appropriate  mailbox  account  which  is  determined  by  the 


specific  subscriber  to  which  the  message  is  addressed  and  the  classification  of  the  message.  The  E-mail 
header  is  removed  when  the  message  is  transferred  to  and  from  the  LDMX  or  GatcGuard,  depending 
on  which  way  the  transmission  is  initiated.  The  E-mail  header  is  only  used  for  the  internal  processing 
within  the  MMS.  Figure  5  demonstrates  mc.ssage  (low  procedures  from  the  LDMX  to  the  Gateguard. 
The  process  for  message  flow  from  a  GateGuard  to  the  LDMX  is  opposite  of  that  shown  in  Figure  5, 


excluding  accc.ss  control  proce.sscs  such  as  sub.scribcr  logon  and  authentication.  [Ref.  23;  p.  3-21] 


MESSAGE  FLOW 


Figure  5  Message  flow  procedures  from  LDMX  to  Gateguard 
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MMS  utilizes  an  RIXT  protocol  conversion  to  make  the  MMS  appear  to  be  an  RIXT  to 
the  LDMX.  Besides  converting  the  protocol,  the  process  will  ensure  that  the  classification  link  between 
the  LDMX  and  the  MMS  is  not  exceeded.  Me.ssages  will  be  delivered  to  both  the  LDMX  and  the 
Gateguard  by  First  in  First  Out  (FIFO)  precedence.  |Ref.  23:  p.  3-21  j 

a.  Access  Control  and  Authentication 

Access  to  the  MMS  will  be  controlled  by  a  MLS  Operating  System.  Sub.scribers  must 
be  capable  of  presenting  identification  and  authentication  (password)  information  that  is  recognized  by 
the  M.MS  TCB.  The  ID  and  password  will  map  to  mailbox  accounts  and,  in  conjunction  with  the  security 
of  the  data  port  used  to  access  the  MMS,  to  a  security  level  the  subscriber  is  authorized  to  access.  [Ref. 
23:  p.  3-24) 

STU-III’s  with  a  STU-lIl  Acce.ss  Control  System  (SACS)  will  be  used  to  provide 
synchronous  dial-up  communications  between  the  GatcGuard  and  MMS  over  the  public  telephone 
switched  network  SACS  will  authenticate  subscribers  prior  to  gaining  access  to  the  MMS  through  a 
feature  which  provides  affirmative  authentication  of  a  specific  user  bv  Key  ID  and/or  Department 
Agency  or  Organization  (DAO)  code.  SACS  will  be  maintained  and  updated  bv  system  operators  at  the 
NTCC.  SACS  will  prevent  the  calling  partv  from  c.stablishing  a  link  if  the  calling  party  is  not  listed  on 
the  access  control  list  within  .SACS.  Separate  telephone  numbeis  will  be  provided  for  each  of  the  three 
message  classifications.  |Rcf.  2.3:  p.  3-24|  Figure  6  provides  an  overview  of  MMS  interfaces. 

b.  Support  Software  Environment 

The  Secure  Mail  Package  must  be  compatible  with  the  System  V/MLS  operating 
system.  The  intended  database  management  system  to  be  utilized  is  the  UNIFY  2000,  along  with  the 
PRELUDE  office  automation  system.  These  and  any  other  compiled  software  application  programs 
must  be  compatible  with  the  operating  system.  It  is  not  anticipated  that  this  will  be  a  problem  because 
the  mentioned  systems  are  available  through  the  SMSCRC  commodities  contract  which  is  the  contract 
vehicle  for  the  procurement  of  the  .software  and  hardware  for  the  MMS.  (Ref.  23:  p.  4-4) 
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Figure  6  MMS  interfaces 


D.  MESSAGE  DISSEMINATION  SUBSYSTEM 

As  stated  previously  DMS  is  a  system  in  the  sense  that  its  components  work  together  to  perform 
a  function,  it  is  the  result  of  many  separate  dewelopmenl  and  ac(|uisiiion  activities.  The  Message 
Dissemination  Subsystem  (MDS)  is  one  of  these  components  and  is  being  implemented  in  a  non- 
DCS/NTS  Automated  Information  (.AlS)  supporting  DoD  me.ssaging.  |Ref.  24) 

!•  MDS  Objectives 

The  MDS  system  is  designed  to  provide  a  system  to  automate  organizational  messaging 
handling  procedures.  The  system  was  deigned  based  on  the  following  objectives  |Ref.  24:  p.  3): 

•  To  eliminate  manual  message  dissemination  procedures  requiring  me.ssage  reproduction  and 
courier  services. 

•  To  operate  at  the  system  high  security  level  of  an  organization's  LAN  and  ADP  .systems. 
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•  To  require  that  all  user  terminals  be  IBM  PC  compatible  with  a  connecting  LAN  and  file  server. 

•  To  implement  file  server  and  user  terminal  software  that  is  POSIX  and  MS-DOS  compatible. 

•  To  provide  file  transfer  of  messages  in  accordance  with  Navv  formats,  transparent  to  the 
operating  environment. 

•  To  use  X.400/X.500  compatible  design  considerations  permitting  upgrade  through  commercial 
operating/netw'ork  .system  enhancements. 

•  To  use  COTS  equipment  and  systems  software  to  lake  advantage  of  technology  advancements 
in  the  area  of  office  automation. 

•  To  migrate  using  COTS  and  Non-Dcvclopmenlal  items  evolutionary  implementation  to  the 
Government  Open  Sy.stems  Interconnection  Profile  (GOSIP). 

2.  Functionul  Description 

The  MDS  will  electronically  .send,  receive  and  disseminate  messages  by  utilizing  a  PC 
LAN.  MDS  is  designed  to  accept  input  from  standard  diskette  or  Autodin  messages  from  GatcGuard. 
Additionally,  MDS  is  capable  of  disseminating  inter-office  memos,  individual  DDN  E-mail,  and  an 
organizational  message  summary.  The  di.stribution  of  organizational  mc.ssages  is  the  focus  of  this  thesis, 
consequently  attention  will  only  be  fv)cu.sed  on  the  organizational  message  dissemination  capabilities  of 
MDS. 


Basic  components  of  the  MDS  include  IRcf.  24;  p.  17); 

•  PC  LAN  -  A  PC  L.AN  and  file  .server  will  provide  the  medium  for  the  electronic  distribution  of 
organizational  message  traffic. 

•  The  Me.ssagc  Dissemination  Sub.sysiem  File  Server  (.MDSFS)  -  is  the  component  of  MDS  that 
will  be  resident  on  the  file  .server.  This  file  .server  will  allow  the  dislrilmlion  of  incoming  or  back- 
routed  outgoing  organizational  mc.ssages  to  the  AlS  u.sers. 

•  The  MDS  User  Interface  Program  (MDSUIP)  -  is  the  component  which  allows  acce.ss  to  the 
organizational  message  files  created  by  the  .MDSFS.  The  MDSUIP  will  allow  a  user  to  select  and 
view  an  organizational  message. 

•  Marine  Corps  Text  Format  Editor  (MTF  Editor)  -  The  MTF  Editor  is  user  PC  software  that 
allows  a  user  to  create,  format,  edit,  and  output  an  organizational  mes.sagc  in  accordance  with 
required  DoD  message  formats. 
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a.  MDSFS  Messa^  Input  and  Queuing 

The  MDSFS  wil!  rceci\e  formaitcd  message  via  GatcCJuard  (utilizing  the  KERMIT 
protocol)  or  from  (lopp)  diskette  and  cop_\  them  to  a  directory  in  the  MDSFS  file  server.  As  specified 
by  the  user,  the  MDSFS  will  poll  the  directory  and  when  messages  are  present  the  .MDSFS  distribution 
process  will  begin.  Distribution  entails  automatically  searching  the  message  for  key  information. 
Messages  addressed  to  Navy  shore  commands  require  the  originator  to  include  office  code  routing 
indicators  in  the  format  of  the  message,  thus  the  key  information  could  be  very  easy  to  obtain.  Once 
receiving  user  offices  have  been  identified,  a  temporary  log  will  be  updated  to  facilitate  distribution 
proce.ssing.  Each  user  work  .station  will  have  a  me.s.sagw  summary  file  in  their  PC  LAN  file  .server.  The 
summary  will  contain  records  of  iirgani/.ition.il  mess.tges  that  have  been  distributed  by  the  .MDSFS.  As 
new  mes.sages  are  received  they  will  be  appended  to  the  u.ser's  mcs,sage  summary.  |Ref.  24;  p.  .10] 

b.  MDSUIP  Messa^  Selection  and  Delivery 

The  MDSUIP  component  of  the  .MDS  is  the  user  workstation  .software.  It  provides 
the  user  with  a  method  of  scanning  and  .sorting  mcs.sage.s  w^titing  fur  inspection  or  action.  Users  will 
access  their  respective  message  summary  file  to  review  messages  awaiting  their  inspection.  The  databa.se 
records  will  include  critical  information  about  the  message,  such  as  the  Originator.  Datc-Time-Group, 
Subject,  classification,  and  precedence.  The  database  will  be  reviewed  in  a  summary  line  format  alhwving 
the  user  to  view  characteri.stics  of  more  than  twenty  me.ssagc  simultaneou.sly.  When  the  user  .selects  the 
message  for  viewing,  the  .MDSUIP  will  retrieve  the  me.s.sage  from  the  common  me.s.sage  directory  for 
viewing.  The  file  will  not  be  ctipied  but  only  read  into  the  user  workstation's  memory.  U.scrs  will  not 
have  a  write  capability  to  the  original  mes.sage.  This  intended  to  preserve  me.s.sagc  integrity;;  however, 
a  user  may  rcque.st  the  path  and  file  name  of  the  message.  |Ref.  24;  p.  .1.1] 


V.  TRUSTED  XENIX  AND  VERDIX  SECURE  LOCAL  AREA  NETWORK 


The  purpose  of  this  chapter  is  to  describe  two  products  that  are  commercially  available  today. 
The  author  chose  the  Trusted  XENIX  and  Verdix  Secure  L/^N  because  they  arc  two  products  that  have 
been  formally  evaluated  by  the  NCSC  to  meet  B2  criteria.  The  primary  references  that  support  this 
chapter  consists  of  company  literature  that  does  not  disclose  proprietary  information.  One  must 
remember  that  the  literature  is  primarily  used  to  sell  the  individual  products;  however  the  author  is  only 
referencing  literature  that  provides  a  functional  description  of  the  two  products.  The  formal  NCSC 
evaluation  justifies  the  presentation  of  these  two  products.  The  author  is  not  endorsing  any  of  the 
products,  but  only  desires  to  review  the  capabilities  to  demonstrate  how  the>  may  be  applied  to  a 
shipboard  multilevel  .secure  LAN. 

Tru.sicd  Information  Systems  produces  Tru.stcd  XENIX,  a  Iru.sted  operating  .sy.stem  that  controls 
information  access  to  specific  individuals  and  the  network  frt)m  the  wt)rkstation.  Verdix  Secure  LAN 
(VSLAN)  components  control  the  lltAV  of  inlormalion  to  each  network  component  (e.g.,  server, 
workstation,  gatewas,  printer).  Coupled  with  software,  integration  of  the  two  prt)ducts  allows  for  the 
exchange  of  compatible  security  labels,  providing  a  MLS  solution  to  many  requirements. 
[Ref.  25] 

A.  TRUSTED  XENIX 

Trusted  XENIX  is  a  multilevel  secure  operating  system  for  IBM  Personal  Computers  and  fully 
compatible  clones.  The  Trusted  XENIX  System  consists  of  three  components.  The  Trusted  Xenix 
Operating  System  is  the  base  component  and  a  prerequisite  for  the  other  components.  The  operating 
system  performs  .several  functions  which  include,  enforcing  mandatory  and  discretionary  .security  policies, 
performing  user  identification  and  authenlicaiion,  generating  audit  trail  and  accounting  records,  and 
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providing  a  base  lu  build  secure  application  programs.  The  second  component,  the  Trusted  Xenix 
Development  System,  provides  a  set  of  application  development  software  tools,  including  the  C 
programming  language.  The  Trusted  Xenix  Text  Formatting  Svstem  is  the  thii  d  component  and  pros  ides 
high-level  formatting  macros  for  document  preparation.  (Ref.  26) 

1.  Environmental  Strengths 

Trusted  Xenix  enforces  a  least  privileged  u.ser  principle,  allowing  each  user  to  perlorm  only 
those  functions  required  to  perform  their  respective  tasks.  Noimal  u.ser  functions  include  tasks  such  as 
running  application  software,  creating  and  deleting  their  file.s,  and  using  editors.  There  arc  five  different 
privileged  user  roles  in  addition  to  the  normal  users.  They  include  a  System  Security  Administrator, 
Secure  Operator  Account  Administrator,  and  a  Trusted  System  Programmer  and  Auditor.  One  person 
may  fulfill  the  role  of  more  than  one  function;  however,  they  can  only  act  in  one  capacity  per  login 
session.  A  wide  range  of  auditing  capabilities  are  available,  including  all  actions  taken  by  privileged 
users.  (Ref.  26] 

2.  Communications  Support 

Separate  from  the  operating  system  software.  Tru.sted  Iniormalion  Sy.stems  also  offers  a 
communication  software  package.  This  soltware  includes  three  network  TCP/IP  applications,  single 
network  TCP/IP,  dual  network  TCP/IP,  and  Multilevel  TCP/IP,  each  targeted  towards  different 
consumers  with  specific  security  needs  to  meet  their  LAN  configurations.  Additionally,  a  Multilevel 
STU-lIl  software  package  is  included  in  th.e  software  package.  By  utilizing  this  communications  package, 
the  Trusted  XENIX  user  can  communicate  with  an  unlimited  number  of  users.  The  TCP/IP  programs 
provide  a  fully  capable  set  of  standard  protocols  including  [Ref.  26); 

•  Transmission  Control  Protocol  (TCP)  -  provides  reliable  data  transfer  between  computers. 

•  Internet  Protocol  (IP)  -  enables  data  to  be  transferred  across  netw'orks  using  different 
technologies,  e.g.  X.25  and  IEEE  802.3. 

•  File  Transfer  Protocol  (FTP)  -  transfers  files  between  computers. 

•  Simple  Mail  Transfer  Protocol  (S.MTP)  -  .sends  and  receives  mail  between  computers. 
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•  Telnet  Protocol  -  provides  for  login  on  remote  computer  systems. 

The  Multilevel  STD-IIl  Software  automates  the  setting  of  the  Trusted  XENIX  security 
level  for  the  STU-llI  serial-port  connection  by  using  special  security  labels  provided  by  the  STU-111 
hardware  device.  This  eliminates  the  possibility  of  operator  error  and  allows  for  remote  multilevel 
security  operations  with  STU-III  communications  security  protection.  [Ref.  26] 

B.  VERDIX  SECURE  LOCAL  AREA  NETWORK 

The  VERDIX  Secure  LAN  (VSLAN)  is  a  network  component  that  is  capable  of  interconnecting 
hosts  systems  operating  at  different  security  levels.  The  system  mediates  access  between  hosts,  it  does 
not  mediate  access  attempts  to  host  processes  to  information  on  host  systems.  It  is  intended  to  be  used 
as  a  trusted  building  block  upon  which  complete  trusted  network  systems  can  be  built.  [Ref.  27] 
The  VSLAN  was  developed  to  provide  the  following  services  to  its  hosts  [Ref.  27]: 

•  A  system  bus  interface. 

•  A  datagram-orientated  communications  service. 

•  Mediation  of  all  data  transfers  between  attached  hosts  in  accordance  with  the  VSLAN  mandatory 
and  discretionary  access  control  policies. 

•  identification  and  authentication  of  the  individual  responsib'e  for  operating  a  node  of  the 
network. 

•  Centrali/.ed  management  functions  for  security  ofllcers  to  exerci.se  contiol  over  the  operation  of 
VSLAN. 

•  A  capability  to  protect  host  datagrams  and  VSLAN  control  information  again.st  modification  by- 
random  transmission  errors. 

The  VSLAN  supports  the  Ethernet/IEEE  802.3  protocol  and  provides  backplane  compatibility 
with  most  microcomputers,  minicompute-s,  and  workstations  including  PC-Bus  (286/386  PCs),  VMEbus 
(i.e.,  SUN  workstations),  3B2  Bus  (AT&T  3B2),  and  NuBus  (Apple  MAC  11).  The  system  also  includes 
an  eight  port  terminal  server  that  supports  TCP/IP  and  Telnet  protocols.  VSLAN  is  transparent  to  host 
operating  systems  and  higher  level  protocols,  supporting  various  versions  of  UNIX,  V.MS,  and  DOS. 
[Ref.  27] 
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1. 


Product  Overview 


The  VSLAN  iinplenicnis  a  Network  TCB  distributed  over  a  LAN  of  various  host  systems 
and  interface  components.  The  Network  TCB  pro\ides  intcrconnectivity  between  user  systems  according 
to  a  defined  security  policy,  and  performs  access  control,  identification,  authentication  and  audit. 
Enforcement  of  the  user’s  defined  securit>  policy  is  accomplished  by  hardware,  software,  and  firmware 
built  into  the  system.  The  desired  security  policy  is  input  via  parameters  by  the  Network  Security  Officer 
(NSO).  The  NSO  is  the  individual  responsible  for  administering  security  on  the  network.  [Ref.  27] 

A  .secure  LAN  consi.sts  of  a  single  VERDIX  Nctw'ork  Security  Center  (VNSC)  and 
multiple  Verdix  Network  Securits  De\ices  (VNSDs),  which  are  \ery  similar  to  the  TlUs  discussed  in 
Chapter  11.  The  VNSC  piovides  the  capabilities  for  the  NSO  to  control  and  audit  security  aspects  of  the 
network.  The  VNSD  is  the  LAN  interface  that  addresses  functional  areas  of  access  control,  encryption 
and  communications.  The  VNSD  mediates  incoming  and  outgoing  p<""kets  bd.sed  on  the  defined  security 
parameters  implemented  by  the  NSO  through  the  VNSC.  [Ref.  27] 
a.  The  Verdix  Network  Security  Center 

The  VNSC  manages  the  security  operations  of  the  VSLAN.  The  VNSC  is  a  dedicated 
workstation  which  includes  secure  network  management  .software  and  a  built  in  secure  LAN  interface. 
The  VNSC  generates  authentication  keys  for  network  initiali/cation  and  crtmmunicatcs  transmit  and 
receive  security  policies  for  users  of  the  LAN.  Additionalh,  the  VNSC  maintains  audit  trails  of  network 
activity  and  generates  audible  and  visual  alarms  when  securitv  violation  attempts  occur.  [Ref.  27] 

The  VNSC  programs  a  Personal  Identification  Device  (PID)  for  each  user.  The  users 
communicate  an  initialization  request  to  the  VNSC  by  inserting  their  PID  in  the  VNSD  key  receptacle. 
The  VNSC  then  authenticates  the  trusted  V'NSD,  and  alerts  if  the  initialization  fails  authentication. 
Proper  authentication  establishes  a  trusted  path  of  communication  between  the  VNSC  and  the  VNSD. 
The  VNSC  then  downloads  the  data  access  rules  to  the  VNSD.  These  data  access  rules  define  "security 
windows"  through  which  data  can  be  received  or  transmitted  consistent  with  the  predefined  security 
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policy.  The  \vindo\v.s  define  the  levels  and  categories  of  data  which  can  be  received  and  transmitted.  The 
"receive  security  window"  defines  data  the  node  can  receive  fioni  the  LAN,  and  the  "transmit  window" 
defines  the  data  the  node  mav  transmit  to  the  LAN.  Complete  audit  trails  are  maintained  on  all  security 
related  events.  The  software  for  VNSC  includes  all  system  and  application  software  required  for  network 
and  security  management.  The  software  cannot  be  modified  by  the  user.  The  VNSC  is  a  specially 
configured  computer  equipped  with  audible  alarms.  It  also  includes  a  VGA  monitor  and  audit  printer. 
The  VNSC  interfaces  directly  to  the  IEEE  Ethernet/802.3  LAN.  (Ref.  27] 
b.  The  Verdix  Network  Security  Device 

The  Verdi.N  Network  Secuiity  Device  (VNSD)  is  the  secure  interface  to  the  VSLAN. 
It  is  a  trusted  interface  that  functions  as  a  multilevel,  multi-compartment  component  and  mediates  the 
flow  of  data  between  LAN  nodes.  The  VNSD  enlorces  the  network  security  policy  by  verifying  every 
attempted  data  transfer  again.st  the  data  access  rules  implemented  by  the  VNSC.  The  VNSD  checks  that 
the  security  label  of  the  data  is  consistent  with  both  the  transmit  and  receive  windows.  All  data  not 
satisfying  the  transmit  and  receive  .security  checks  are  rejected  and  the  VNSC  is  alerted  to  the  attempted 
violation.  (Ref.  27] 

The  VNSD  hardware  is  available  in  several  board-level  configurations.  They  are 
functionally  identical,  yet  each  provides  for  a  different  host  bus  interface.  The  VNSD  contains  a 
communication  interface,  data  separation  kernel,  authentication  key  interface,  encryption  hardware, 
processor,  and  memory  for  the  \'NSD  program  and  data.  Interaction  between  the  modules  is  performed 
via  a  local  address/data  bus  driven  by  the  master  processor  and  Ethernet  blocks.  The  VNSD  is  driven 
by  the  16-bit  Intel  80286  microproce.s.sor  and  u.ses  the  Intel  82.586  micro  controller  to  provide  IEEE 
802.3  media  access.  The  board’s  RAM  is  divided  into  three  banks.  One  dual  ported  memory  bank  is 
shared  with  the  CPU  and  the  host,  and  one  is  shared  between  the  CPU  and  the  Ethernet  module.  The 
remaining  RAM  is  reserved  for  local  menurry  for  the  VNSD  CPU  module.  Each  of  the  modules  is 
logically  separated  and  can  only  be  accessed  through  the  appropriate  modules.  (Ref.  27] 
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The  software  for  the  VNSD  was  developed  by  VERDIX  and  is  stored  as  firmware 
on  its  board.  The  firmware  executes  all  of  the  V’NSD’s  functions,  including  enforcing  securits  policy, 
transmitting  and  receiving  data,  auditing,  encrypting,  and  initiali/ing.  (Ref.  27) 

2.  Coinmunicutiaii  Frotueols 

The  VSLAN  operates  at  the  physical  and  data  link  layers  of  the  Open  Systems 
Interconnection  (OSI)-  Basic  Reference  Model.  VSLAN  utilizes  the  IEEE  802.3  protocols  to  handle  the 
physical  layer  and  a  portion  of  the  data  link  layer.  The  VERDIX  implementation  differs  from  the  IEEE 
standard  in  one  respect;  the  IEEE  standard  defines  a  two-byle  length  field,  which  indicates  the  length 
of  the  datagram.  VERDIX  uses  this  field  to  identify  the  .source  VNSD  ID  or  principal  ID  (depending 
on  whether  a  data  oi  control  association  has  been  established).  A  specific  length  indicator  is  not 
included  in  'he  datagram.  Instead,  the  receiving  VNSD  determines  the  end  of  the  datagram  by  the 
quiescence  of  the  line.  It  strips  off  the  last  .32  bits  of  the  received  me.ssage  for  comparison,  and  is  able 
to  determine  the  end  of  the  data  field.  The  "CSMA/CD  Access  Method  and  Physical  Layer 
Specification,"  IEEE  802.3,  does  not  require  acknowledgement  transmissions  to  indicate  that  datagrams 
have  been  received.  (Ref.  27] 

The  protocols  residing  at  VSLAN  data  link  layer  include  the  IEEE  802.3  Media  Access 
Control  protocol,  an  encryption  protocol,  and  a  logical  link  protocol.  Except  for  the  length  of  the  data 
field,  VSLAN  Media  access  protocol  conforms  to  the  IEEE  standard.  Because  of  the  need  for  reliable 
communication  between  the  VNSC  and  the  VNSD,  the  VSLA.N  protocol  suite  includes  a  logical  link 
control  protocol.  This  protocol  provides  a  reliable  data  transfer  .service  for  network  control  datagrams 
only.  This  ia  accomplished  by  specifying  separate  data  and  acknowledgement  datagrams.  The  receiver 
accepts  only  datagrams  in  .sequence  and  generates  acknowledgements  that  identify  the  received 
datagrams  by  sequence  number.  Packets  prepared  by  the  logical  link  priitocol  are  treated  as  data  by  the 
encryption  protocol.  The  Data  Encryption  Standard  (DES),  described  in  Cihapter  II,  is  primarily  used 
as  a  data  integrity  mechanism,  in.stcad  of  a  mechanism  to  control  .security  policy.  (Ref.  27] 


The  VSLAN  operates  transparently  to  higher  layer  protocols  (e.g.,  X.25)  implemented  on 
hosts.  Because  of  its  independence  from  these  upper  layer  protocols  the  VSLAN  sy.stem  can  be  used 
to  integrate  a  variet>  of  host  .systems.  E\en  though  the  VSLAN  can  support  communications  betsseen 
different  host  systems,  host  systems  mu.st  implement  compatible  upper  layer  protocols  suites  to  be  able 
to  communicate  with  one  another.  |Ref.  27) 


C.  SUMMARY 

The  above  information  pros  ides  a  brief  overall  description  of  two  commercial  products  that  have 
met  formal  DoD  evaluation  criteria.  The  XENIX  operating  system  provides  MLS  for  the  host  while  the 
VERDIX  Secure  LAN  provides  for  the  security  and  proper  routing  of  information  across  the  LAN 


Figure  7  Example  of  VERDIX  .secure  local  area  network 


VI.  A  MULTILEVEL  SECURE  SHIPBOARD  LAN  PROPOSAL 


The  purpose  of  this  chapter  is  to  present  a  hypothetical  multilevel  secure  shipboard  LAN 
installation  using  the  MMS,  the  MDS,  the  XENIX  Trusted  Operating  System  and  the  VERDIX  Secure 
Local  Area  Network,  described  in  the  previous  chapters.  The  hypothetical  LAN  will  be  based  on  the 
requirements  of  a  medium-sized  ship;  a  generic  destroyer  and/or  cruiser  scenario  will  be  developed.  By 
generic  the  author  is  implying  a  general  description  of  node  location  and  desired  classification  processing 
capabilities.  Specific  ships  will  differ  due  to  their  ADP  assets  (number  and  type  of  computers)  and 
command  prerogative  of  how  certain  administrative  proce.sses  will  function  (e.g.,  what  nodes  can  process 
Secret  and  below  as  oppo.sed  to  Confidential  and  below).  The  generic  ship  de.scription  is  developed  from 
the  author’s  eight  years  of  shipboard  c.'iperiencc  on  four  different  ship  classes  which  include  one  Frigate, 
one  Destroyer,  and  two  (Juided  Missile  Cruisers. 

A.  SHIPBOARD  LOCAL  AREA  NETWORK  OVERVIEW 

The  primary  purpose  of  the  hypothetical  LAN  is  to  provide  the  capability  of  proces.sing  various 
classified  organizational  messages  between  the  Main  Communications  Center,  hereafter  referred  to  as 
Radio  Central,  and  various  nodes  throughout  the  ship.  The  ultimate  goal  is  the  termination  of  message 
paper  reproduction  for  the  internal  distribution  of  AUTODIN  messages  throughout  the  ship  (which 
parallels  a  goal  of  the  DMS  with  the  NTCC  and  its  OTC  sub.scribcrs).  The  secondary  goal  is  to  provide 
a  medium  to  replace  the  paper-based  Secret  information  account.  Chapter  One  discussed  the  potential 
use  of  CD-ROM  techniques  in  distributing  tactical  information.  The  LAN  should  be  de.signed  for  future 
upgrades  to  incorporate  this  type  of  features  as  they  become  more  readily  available.  The  tertiary  goal 
is  to  provide  the  foundation  for  an  Office  Automation  Sy.stem  allowing  for  various  levels  of  security  that 
will  conform  to  Privacy  Act  requirements.  An  example  would  be  the  generation  of  personnel  evaluations 


and  subsequent  processing,  including  rc\ie\\ingand  final  appro\aI,  all  conducted  on  the  multilc\el  secure 
LAN. 

1.  Specific  Required  .Attributes 

Specific  attributes  for  the  hypothetical  LAN  are  .somewhat  parallel  to  those  of  the  MMS, 
described  in  Chapter  IV,  and  include: 

•  Provide  connectivity  between  NAVMACS.  GateGuard,  VNSC,  and  LAN  nodes 

•  Provide  message  separation  by  classification 

•  Eliminate  manual  outgoing  processing  and  incoming  distribution  of  Unclassified  to  Secret 

AUTODIN  messages. 

2.  Functional  System  Description 

The  following  is  a  sy.stem  description  of  the  hypothetical  LAN  which  includes  assumptions 
concerning  connectivity  and  compatibility  of  application  programs.  These  will  be  highlighted  as  discussed. 
The  hypothetical  LAN  is  based  on  systems  which  have  been  described  in  the  previous  chapters.  The 
intent  is  to  draw  upon  existing  developments  and  relate  them  to  indicate  that  a  multilevel  shipboard 
secure  LAN  is  feasible. 

a.  Communications  Suite  and  Interfaces 

The  communications  suite'  of  the  ship  is  assumed  to  be  the  NAVMACS  V.'?  variant. 
The  NAVMACS  software  will  be  modified  to  .send  all  addressed  me.ssages  to  both  PRl  and  TP2.  A  BIU 
or  BIC  is  installed  to  connect  NAVMACS  to  GateGuard.  GateGuard  has  a  communications  port  with 
STU-lII  access  to  receive  me.ssages  from  the  servicing  NTCC  while  the  ship  is  in  port.  GateGuard  is 
installed  in  the  Radio  Central  which  is  either  manned  or  physically  locked  and  alarmed.  The  NA\'MACS 
interface  simply  allows  incoming  messages  to  be  transferred  to  GateGuard  in  their  DoD  predefined 
format  (JANAP  128  or  modified  ACP  126). 
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b.  GaleGuard,  MMS,  and  LAN  Interfaces 


GateGuaid  will  be  inlcrfaced  to  a  shipboard  MMS.  A  method  of  emulating  a  STU-lIl 
connection  of  the  highest  security  level  will  have  to  be  developed.  This  will  allow  the  MMS  to  accept 
Unclassified  to  Secret  me.ssagc  traffic  from  the  GateGuard  during  the  same  transfer.  Otherwise,  a 
GateGuard  capable  of  separating  message  traffic  by  classification  will  be  required.  Three  ports  would 
carry  the  associated  classified  traffic.  Essentially  the  GateGuard  would  emulate  the  NTCC’s  LDMX 
connection  to  the  M.MS. 

A  MDS  system  will  be  required  up.stream  of  the  MMS  to  interrupt  the  message  and 
determine  to  which  shiphoiird  subscriber  mailboxes  the  me.ssages  should  be  posted.  The  MMS  at  the 
NTCC  is  able  to  read  the  DoD  format  of  the  me.ssagc  which  includes  the  Plain  Language  Addressee 
and  associated  Routing  indicator  which  every  Na\y  command  is  a.ssigned.  This  is  how  a  subscriber 
account  is  identified  at  the  NTCC.  At  the  shipboard  level  an  application  interface  will  be  required  to 
read  the  message  and  determine  which  shipboard  subscribers  should  receive  the  message.  A  shipboard 
subscriber  will  have  to  be  defined  as  an  individual  node  or  an  organisational  title  position  within  the 
command,  such  as  Commanding  Officer  or  Executive  Officer.  The  appiicu  .program  would  modify 
or  append  a  local  shipboard  R1  to  the  mcs.sage  that  the  M.M.S  would  recognise.  Another  option  is  to 
simply  post  all  messages  of  tht  same  classification  tv)  v)nc  subscriber  account  and  then  aliv,vv  authorised 
nodes  acce.ss  to  the  files  within  the  account.  The  M.M.S  vvvnild  then  append  the  E-mail  header  to  the 
DoD  formatted  message  and  post  it  to  a  subscriber's  mailbox  as  it  is  currently  programmed  to  do  at  the 
NTCC.  A  MDS  .system  would  then  poll  each  sub.scriber  mailbox  and  generate  a  me.ssagc  summary 
profile  allowing  subscribers  to  review  critical  information  about  me.ssages  po.sted  tv)  their  respective 
mailbox  accounts  or  all  me.ssages  contained  in  a  dc.signated  classification  mailbox.  The  MMS  would  then 
be  fitted  with  a  VNSD  on  three  communication  ports  connected  to  the  shipboard  LAN  (one  each  for 
Unclassified,  Confidential,  and  Secret). 

Another  option  is  a  single  communication  port  with  one  VNSD  since  the  VNSC  can 
program  communication  authorization  between  various  \'NSD.s.  The  VNSD  would  be  equivalent  to  the 


STU-lII  and  SACS,  being  programmed  wilh  lian.smil  windim.s  for  each  nude  and  pro\iding  encryption 
capability  the  STU-llI  proside.s.  The  VNSC  would  be  installed  in  the  Radio  Central  and  the  NSO  would 
program  the  required  transmit  and  receive  windows  for  each  node.  Anothei  way  of  describing  the 
author’s  proposal  is  that  the  MMS  w’ould  function  as  a  file  server  for  the  LAN.  Files  and  messages  with 
the  E-mail  header  (the  E-mail  header  would  not  be  required  to  be  stripped  off  as  it  is  in  the  MMS 
NTCC  configuration)  would  be  posted  in  mailbo.x  accounts,  and  if  a  node  is  authorized  to  communicate 
with  the  mailbo.x  a  file  transfer  or  E-mail  transfer  could  take  place. 

A  MDSUIP  w’ould  be  incorporated  to  provide  the  capability  for  viewing  messages 
selected  from  the  me.ssage  summary  profile.  The  file  will  be  lead  to  the  user  woikstation  memory  for 
viewing.  If  the  user  desires  a  copy  of  the  message  a  file  transfer  will  be  required.  A.ssuming  the  \’NSC 
and  \’NSD  are  installed  and  programmed,  an  aulhori/cd  file  transler  will  take  place  and  the 
responsibility  for  providing  multilevel  .security  at  the  workstation  will  be  transferred  to  the  XENIX 
tru.stcd  operating  .system.  This  assumes  the  MDSUIP  is  compatible  with  the  \'ERD1X  and  XENIX 
software. 

3.  Nodes 

The  hypothetical  LAN  will  consist  of  the  following  nodes,  generic  location,  and  security 
classification  processing  requirements: 

1.  Commanding  Officer  s  In  Port  Cabin  -  located  in  the  Commanding  Officer  s  in  port  cabin, 
required  to  process  Secret  and  below. 

2.  Executives  Officer's  .stateroom  -  located  in  the  Executive  Officer's  stateroom,  required  to  process 
Secret  and  below. 

3.  Administrative  Office  -  located  in  t.ie  Administrative  Office,  required  to  process  Secret  and  below. 

4.  Personnel  Office  -  located  in  the  Personnel  Office,  required  to  proce.ss  Confidential  and  below. 

5.  Supply  Departmental  Office  -  located  in  the  Supply  Departmental  i)ffice.  two  workstations  may 
be  active,  required  to  process  Confidential  and  below. 

6.  Combat  Systems  Departmental  Office  -  located  in  the  Combat  Sy.stems  Departmental  Office, 
required  to  proce.ss  Secret  and  below. 


7.  Operations'  Departmental  OlTice  -  located  in  the  Operations’  Departmental  Office,  required  to 
process  Secret  and  below. 

8  Engineering  Departmental  Office  -  located  in  the  Engineering  Log  Room,  required  to  process 
Confidential  and  below. 

9.  Command  Master  Chiefs  Office  -  located  in  the  Command  Master  Chief  Office,  required  to 
process  Confidential  and  below. 

10.  3M  Coordinator’s/Ship’s  .Maintenance  Officer  Office  -  located  in  the  designated  office  space, 
required  to  process  Confidential  and  below. 

11.  Electronic  Repair  Shop  -  located  in  the  Electronic  Technicians’  workspace,  required  to  process 
Confidential  and  below. 

12.  Main  Communications  Center  (Radio  Central)  -  located  in  Radio  C'entral.  required  to  process 
Secret  and  below. 

1.3.  Combat  Information  Center  (  Three  separate  workstations)  -  located  in  CIC.  required  to  process 
Secret  and  below. 

14.  Pilot  House  -  located  in  the  Pilot  Hou.se.  required  to  proce.ss  Secret  and  below. 

15.  Various  Officer  staterooms  -  located  throughout  the  ship,  reijuired  to  proce.ss  Confidential  and 
below. 

16.  Various  admini.stratisc  offices  -  offices  that  certain  ship  configurations  will  allow  depending  on 
space  and  command  prioritv,  examples  include  a  Command  Career  Counselor  office  and  an 
Educational  Services  Officer  office.  Additionally  these  offices  ma\  coe.xist  with  an  existing  office  but 
require  a  separate  node,  an  example  would  be  the  Command  Career  Counselor  and  Command 
Master  Chief  sharing  an  office  space  but  having  two  separate  nodes  within  the  same  space. 

4.  .Assuniptiuns 

The  author  has  made  certain  assumptions  in  the  theoretical  LAN  which  include: 

•  The  topologN  and  transmission  medium,  coaxial  cable  or  optical  fiber,  are  pinsical  characteristics 
that  support  the  LAN.  Specific  discu.ssion  and  requirements  ha\e  been  intentionally  omitted, 
assuming  that  they  will  not  limit  the  operation  rif  the  applications. 

•  Application  proce.sses  described  in  the  pr. vious  chapters  will  be  compatible  or  be  made 
compatible  with  relatively  easy  effort. 

•  The  MMS  will  act  as  the  file  server  fur  the  organization's  messages.  Other  processes  and 
applications  may  be  required  to  be  installed  to  provide  .separate  functions  for  the  LAN.  The 
author  has  assumed  the  M.MS  has  the  capability  to  do  this. 

•  Database  management  programs  arc  available  and  compatible  with  the  -XENLX  tru.stcd  operating 
system. 
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Application  Scenarios 


The  following  scenarios  are  provided  to  assist  in  understanding  the  application  processes 
the  author  has  described. 

a.  Scenario  One :  Secret  Message 

A  Secret  message  scenario  is  described  below. 

1.  A  Secret  general  service  me.s.sagc  is  addressed  to  USS  ONE  and  transmitted  over  the  fleet 
broadcast  while  the  ship  is  underway.  The  NAV.MACS  \'3  determines  the  message  is  addressed  to 
its  ship  from  the  user  entered  Command  Guard  List.  The  subject  of  the  message  is  "Electronic 
Warfare  Alert."  The  message  is  received  by  NAV.MACS  and  is  downloaded  to  GatcGuard  through 
the  BIU. 

2.  GatcGuard  transfers  the  mc.ssagc  to  MMS  through  the  STU-Ill  emuiation  cvmncction.  The  MMS 
retrieves  the  me-.ssage,  appends  the  E-mail  header  for  internal  processing,  and  po.sts  the  message  to 
the  command’s  Secret  sub.scriber  mailbo.x  account. 

3.  The  .MDS  polls  the  Secret  mailbo.x  account  and  recognizes  the  new  message.  Specific  format  fields 
arc  written  to  the  me.ssage  summary  profile.  The  command’s  message  summary  profile  is  tran.smiltcd 
to  all  nodes  on  the  LA.N.  (The  frequency  of  transmitting  updated  me.ssage  summary  profiles  will  be 
input  by  the  command  .system  admini.stralor.) 

4.  The  Commanding  Officer  logs  on  to  his  PC  in  his  stateroom.  He  inserts  his  PID  into  his  node’s 
VNSD  which  identifies  him  as  the  Commanding  Officer  and  his  associated  pre-programmed  transmit 
and  receive  windows.  He  reviews  the  message  summary  profile  and  desires  to  review  the  scenario’s 
message.  THE  MDSUIP  requests  the  message  be  read  to  the  Commanding  Officer’s  node  memory. 
The  VNSD  on  the  MMS  recognizes  that  the  transmit  and  receive  windows  arc  allowed  for  the  Secret 
classification  and  the  message  with  the  E-mail  header  appended  is  read  into  the  memory  of  the  CO's 
computer.  (The  author  has  suggested  leaving  the  E-mail  header  appended  to  allow  for  the  fca.sibiliiy 
of  utilizing  the  E-mail  application  program  which  may  make  it  easier  for  application  program 
compatibility.)  The  CO  reviews  the  me.ssage  and  de.sires  a  permanent  copy  of  the  message.  He  now 
initiates  a  file  transfer  of  the  me.ssage.  Again  the  VNSDs  recognize  that  the  communication  process 
is  authorized  and  a  file  transfer  is  conducted.  Once  the  file  is  received  the  Xenix  operating  system 
recognizes  the  me.ssage  classification  and  files  the  message  in  an  appropriately  protected  area  of  the 
computer  memory  through  the  implemented  data  base  management  .sy.stem. 

b.  Scenario  Two:  Command  Mandated  Special  Catefpry  Message 

The  purpose  of  this  scenario  is  to  demonstrate  the  fle.xibilily  the  propo.sed  sy.stem 
could  offer.  This  scenario  is  predicated  on  the  author's  experience  that  indiv  idual  Navy  commands  desire 
to  internally  route  certain  Unclassified  messages  in  accordance  with  the  Commanding  and  E.xccutivc 
Officers’  prerogative. 


1,  An  Unclassified  general  message.  uilhi)ut  an\  NavA  .standard  sjKcial  handling  inslructii)ns  is 
received  In  U.SS  ONE.  The  ship  is  in  port  and  the  me.ssage  was  transferred  to  the  ship’s  (JateCJuard 
by  the  servicing  area  NTCC's  M.\iS.  The  content.s  of  the  message  include-  .social  securitv  numbers 
of  personnel  who  tested  po.silive  for  sub.stancc  aba.se  from  the  command's  nuest  recent  random 
urinalysis.  The  Executive  Officer  has  mandated  that  this  tvpe  of  message  vvil!  onlv  be  delivered  to 
his  MMS  sub.scriber  account  due  to  previous  incidents  of  unauthori/,ed  disclosure  of  similar  message 
results. 

2.  The  MDS  sy.stem  recognizes  the  mes.sage  bv  contents  and  subject  line.  The  MDS  interacts  with 
the  M.MS  to  po.st  the  me.s.sage  to  the  Executive  Officer’s  individual  sub.scri’oer  account.  Another 
option  is  to  utilize  a  manual  .M.MS  operator  to  screen  all  received  me.ssagts  and  po.st  them  to 
appropriate  subscriber  accounts. 

3-  The  MDS  later  polls  the  Executive  Officer’s  .M.MS  sub.scriber  account  and  generates  a  message 
summary  profile.  The  Executive  Officer  now  has  a  unique  me.ssage  summarv  account  and  recognizes 
that  he  wants  his  own  file  copy  of  this  mes.sage. 

4.  He  inserts  his  PID  into  his  node's  \  .\SD  and  establishes  a  link  with  ihe  .MMS’s  V'NSD.  Both 
VNsDs  recognize  that  transmission  and  receipt  windows  have  be^n  auihori/i.d  and  the  reque.sted 
file  transfer  lakes  place. 

c.  Scenario  Three:  AH  Navy  Messa^ 

This  scenario  describes  the  routing  ol  a  message  addressed  to  all  Navv  command.s. 
commonly  known  as  an  .ALN.A\'.  .Additionallv.  a  MD.S  interface  will  be  assumed  not  to  exist.  As 
mentioned  in  the  previous  example  a  manual  M.MS  v'|>eratv>r  will  Ive  emploved.  .Although  this  .scenario 
docs  not  eliminate  human  intervention  in  internal  me.vsage  routing  proccdure.s.  it  does  offer  an  extreme 
reduction  in  the  number  of  perso-nncl  reijuired  ts»  dis.semin.ite  paper  message  traffic.  This  scenario 
provides  the  po.ssibililv  of  an  interim  .solution  t»>  a  .shiplvoard  multilevel  secure  LAN  while  a  .MDS/  .MMS 
interface  is  developed. 

1.  -An  Unclassified  ALN.A\'  mes.sage  is  received  I'v  USS  ONE  while  underwav.  The  N.A\'MA(’S  \'.3 
is  monitoring  the  fleet  broadcast  and  determines  that  the  me.s.sage  should  Le  received  bv  the  ship. 
N.AV.M.ACS  dowijU)ads  the  .ALN.A\'  message  tv)  (jatcfJuard. 

2.  An  MMS  operator  pidls  (iaieOuard  fiir  recentb.  received  mes.s.iges.  The  (iatefi'iard  transfers  the 
.ALN.A\'  to  the  .M.MS  where  th^  ntessagv  is  jMst^d  awaiting  vvperator  intv.rv(.niion  to  program  specific 
subscriber  accounts  to  which  the  me.s.sage  should  Iv  posted.  The  .MMS  «iiH.rator  reviews  the  mes.sage 
and  based  on  wrinen  routing  guidance  determinvs  the  mess.ig^  should  b»  delivered  to  all  individual 
subscriber  accounts. 

3.  As  individuals  logon  to  their  nodes  through  v»at  the  dav  thev  in.serl  their  PlDs  and  c.stablish 
communications  with  the  .MMS’s  \'NSD.  Again  tran.smil  and  receive  window-s  arc  recognized  and 
the  individual  subscriber  accounts  are  d»)wnU>aded  to  their  respective  node.s.  (Measures  would  l)c 


required  to  prevent  one  node  from  do\.nloading  a  large  account  and  subsequently  preventing  other 
users  from  utilizing  the  network.) 

d.  Scenario  Four:  Personnel  Evaluations 

This  scenario  describes  the  use  of  VSLAN  without  reference  to  a  NAVMACS 
communication  interface.  Its  purpose  is  to  .slum  a  feature  of  V'SLAN  multilevel  security  feature  that  is 
not  communications  related,  but  re(|uires  muililcvel  securitv  characteristics.  The  mandatorj  access 
control  policy  that  VSLAN  employs  mediates  access  between  defined  subjects  and  datagrams.  Each 
datagram  has  a  unique  sensitivity  label  a.s.sociated  with  it  indicating  its  secuiit>  level.  [Ref.  27]  "A 
security  level  is  defined  as  the  combination  of  a  hierarchical  cL.ssilu,.lu)n  and  a  set  of  non-hicrarchical 
categories  that  repre.sents  the  sensitivilv  of  information.  The  VSLAN  ..upporls  up  to  10  classifications 
and  64  categories."  |Ref.  27] 

This  means  the  network  can  be  used  for  much  more  than  providing  a  communication 
medium  for  the  three  classifications  of  messages  that  NAVMACS  would  be  authorized  to  download  to 
GateGuard  Administrative  infoimalion  could  easily  be  classified  a.id  calegori/ed  as  required  or  desired 
by  an  individual  ship.  Evaluations  are  a  prime  example. 

1.  The  regular  annual  evaluation  repc,  'ng  date  for  First  Class  Petty  Officers  is  approaching  and  the 
Executive  Officer  desires  all  draft  evi*'  ations  to  be  submitted  to  his  node  for  review  and  editing. 
Certain  nodes  throughout  the  ship  are  programmed  with  transmit  and  receive  windows  corresponding 
to  the  command’s  desired  .security  and  sensitivity  policy.  In  this  case  the  Executive  Officer  has 
informed  the  NSO  that  he  ilesires  only  departmental  office  nodes  to  communicate  cith  him 
rega.'ding  the  subjects’  evaluations 

2.  A  Chief  Petty  Officer  drafts  a  evaluation  on  the  appropriate  departmental  node  and  it  is  reviewed 
by  the  departmental  chain  of  command.  Once  the  Department  Head  approves  the  evaluation  he 
transmits  it  on  VSLAN  to  the  Executive  Officer’s  node.  This  a.ssumes  compatibility  between  the 
application  program  for  drafting  the  evaluation,  the  node’s  multilevel  secure  operating  sy.siem,  and 
the  VSLAN  operating  system. 

3.  The  Executive  Officer  reviews  all  the  First  Class  Petty  Officers’  evaluations  and  sends  (hem  to  the 
Personnel  Office  for  printing.  (This  scenario  docs  not  discu.ss  factors  of  how  the  ExecuMve  Officer 
completes  his  review.  It  only  shows  how  the  VSLAN  can  be  used  to  automate  the  evaluation  process 
ensuring  privacy  of  all  individuals  concerned.) 
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An  overview  of  iwo  options  of  the  author’s  proposed  LAN  is  shown  in  Figure  8. 


B.  COST  INFORMATION 

Although  the  author  has  not  discoNcred  a  similar  government  system  to  which  to  compare  costs, 
cost  information  is  available  on  selected  components  of  the  hypothetical  LAN  and  arc  summarized 
below.  It  should  be  noted  that  the  node  description  previously  provided  is  the  basis  for  total  costing. 
Although  various  nodes  were  listed  under  several  headings  the  author  will  assume  that  16  nodes  are 
required. 

•  Complete  Trusted  XENIX  System  (Ref.  28) 


(16  at  $3,995) .  $63,920 

•  VNSC  (Ref.  29)(hardw’arc  &  .software;  .  $17,500 
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•  VNSD[Ref.  29] 

(16  al  $4,250) . $68,000 

•  GateGuard  Syslcm  [Ref.  23:  Appendix  C]  . $3,350 

•  3B2/600G  AT&T  Computer  (Non-Tempest)  (Ref.  23:  Appendix  C]  . $3,354 

•  MMS  300MB  Non-removable  disk  (Non-Tempest)  [Ref.  23:  Appendix  C]  . $4,620 

•  MMS  550MB  Removable  disk  storage  (Tempest)  (Ref.  23:  Appendix  C| . $7,000 

•  MMS  Complete  software  (Ref.  23:  Appendix  C]  . $5,190 

•  Miscellaneous  (e.g., Cables,  STU-111  SACS)  .  $50,000 

•  Total  .  $222,934 

The  author  considers  the  above  cost  factors  to  be  liberal,  meaning  actual  cost  will  likely  be 


greater.  Regardless  it  does  provide  insight  and  leads  the  author  to  conclude  that  the  cost  of  installing 
a  shipboard  multilevel  secure  LAN  is  practical,  and  further  investigation  should  be  pursued. 


VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  results  of  this  study  indicate  a  shipboard  multilevel  secure  local  area  network  is  feasible.  The 
Na\7  initiatives  with  the  DMS  are  considered  to  be  a  primary  contributing  factor  to  the  developmental 
process  required  to  implement  a  shipboard  MLS  LAN.  The  key  parallel  factor  between  the  Navy  DMS 
initiatives  and  the  shipboard  MLS  LAN  is  the  implementation  of  the  MMS  at  NTCCs.  The  capability 
to  segregate  messages  by  classification  and  then  distribute  them  to  authori/ed  subscribers  is  what  has 
been  developed  for  the  NTCCs’  operations.  This  is  the  exact  requirement  needed  on  ships.  The  system 
should  be  able  to  be  modified  to  accommodate  the  requirements  of  a  LAN.  Additionally,  the  required 
connectivity  for  the  dalti  source  of  ship  messages,  the  fleet  broadcast,  is  available.  Syncrotech 
Corporation  established  that  various  NA\'M ACS  variants  could  be  connected  to  GalcGuard.  Operating 
systems  for  the  LAN  and  node  computers  are  commercially  available  and  properly  certified  by  DoD 
standards. 

The  Navy  initiatives  with  DMS  have  focused  on  easing  the  message  processing  capabilities  at 
shore  commands.  The  MMS  v\as  designed  to  serve  the  NTCCs  and  the  MDS  was  designed  to  support 
Naval  shore  commands  and  their  associated  LANs.  The  purpose  of  the  NTS  system  is  to  get  messages 
to  fleet  unit.s.  yet  under  the  DMS  initiatives,  no  llect  unit  has  been  incorporated  into  resea. ch 
development.  The  NAVMACS/CjatcGuard  connectivity  .solution  has  not  been  pursued  beyond  the 
Syncrotech  Corporation  report.  NAVMACS  II  is  considered  to  be  the  future  answer  to  an  LAN 
interface  yet  a  MLS  LAN  has  not  been  addressed.  NAVCOMPARS  is  not  even  considered  in  the  Navy 
DMS  plan,  other  than  a  .statement  that  it  warrants  future  consideration.  LAN  in.stallations  on  the 
GEORGE  WASHINGTON  and  YELLOWSTONE  were  initiated  by  the  individual  ships.  One  must 
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conclude  that  ihe  DMS  initiali\es  ma\  benefit  shipboard  application  requiiements  and  an  avenue  for 
mutual  pursuit  should  be  established. 

B.  RECOMMENDATIONS 

The  ability  of  the  MMS  to  be  installed  on  a  ship  and  act  as  a  file  server  for  the  LAN  should  be 
further  investigated.  This  will  require  coordination  within  OP-094.  The  command  responsible  for 
implementing  DMS  within  the  Navy  and  the  command  which  conducted  the  study  for  Commercial  Fiber 
Optic  LANS  For  Naval  Ships  [Ref.  14]  are  both  under  the  cognizance  of  OP-094.  This  thesis  shows  that 
mutual  coordination  would  be  beneficial. 

The  VERDIX  Secure  LAN  and  Trusted  Information  Systems’  XENIX  trusted  operating  system 
should  be  considered  for  shipboard  use.  Their  NCSC  B1  certification  should  facilitate  rapid 
implementation  if  application  software  is  or  can  be  made  compatible. 

The  GateGuard/NAV’MACS  interface  should  be  implemented  regardless  of  the  status  of 
NAVMACS  II  acquisition.  If  the  NAN'MACS  \'.3  and  (ialeguard  can  be  connected  and  a  multilevel 
secure  LAN  in.stalled  on  a  medium-si/e  ship,  the  lessons  Iciirned  could  be  applied  to  larger  ships.  It 
seems  sensible  to  start  on  a  small  scale  and  work  upwards;  for  example,  evaluate  the  LAN  on  a 
destroyer  and  then  on  an  aircraft  carrier. 

The  message  center  integration  is  not  the  only  requirement  for  a  multilevel  secure  LAN. 
Electronic  libraries  are  rapidly  approaching,  and  integration  will  be  required.  Investigation  of  the  MMS 
to  connect  to  CD-ROM  should  be  conducted  to  facilitate  implementation  of  these  libraries. 

The  ships  of  the  Navy  should  not  be  the  last  entities  w'ithin  the  Navy  to  take  advantage  that  a 
LAN  offers.  The  NTS  system  is  designed  to  get  messages  to  the  fleet  -  -  the  end  user  of  the  information. 
The  officers  and  crews  of  the  ships  should  not  be  left  to  wade  through  a  paper-based  information 
system. 
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APPENDIX  A 


SUMMARY’  OF  EVALUATION  CRITERIA  CLASSES 
The  classes  of  systems  recogni/.ed  under  the  trusted  computer  systems  evaluation  criteria  are  as 
follows.  They  arc  presented  in  the  order  of  increasing  desirability  from  a  computer  security  point  of 
view.  [SOURCE;  Department  of  Defen.se 'Tru.sted  Computer  System  Evaluation  Criteria,  "  DoD  5200.28- 
STD,  December  1085,  Appendi.N  C,  pp.  0.'^-04.j 

Class  (D):  Minimal  Protection 

This  class  is  reserved  for  those  systems  that  have  been  evaluated  but  that  fail  to  meet  the  requirements 
of  a  higher  evaluation  class. 

Class  (Cl):  Discretionary  Security  Protection 

The  Trusted  Computing  Base  (TCB)  of  a  class  (Cl )  .sv.stem  nominally  satisfies  the  discretionary  security 
requirements  by  providing  .separation  of  users  and  data.  It  incorporates  some  form  of  credible  controls 
capable  of  enforcing  access  limitations  on  an  individual  basis,  i.e...  ostensibly  suitable  for  allowing  users 
to  be  able  to  protect  prvtject  oi  private  information  and  to  keep  other  users  from  accidentally  reading 
or  destroying  their  data.  Tlie  class  (Cl)  environment  is  cxpetled  to  be  one  of  cooperating  users 
processing  data  at  the  .same  lcvcl(.s)  of  .sensitivity. 

Class  (C2):  Controlled  Access  Protection 

Systems  in  this  class  enforce  a  more  finely  grained  discretionary  access  control  than  (Cl)  systems, 
making  users  individually  accountable  for  their  actions  through  login  procedures,  auditing  of  security 
relevant  events,  and  resource  isolation. 


Class  (Bl):  Labeled  Security  Protection 

Class  (Bl)  systems  require  all  the  features  required  for  class  (C2).  In  addition,  an  informal  statement 
of  the  security  policy  model,  data  labeling,  and  mandatory  access  control  o\er  named  subjects  and 
objects  must  be  present.  The  capability  must  e.xist  for  accurately  labeling  exported  information.  Any 
flaws  identified  by  testing  must  be  removed. 

Class  (B2):  Structured  Protection 

In  class  (B2)  systems,  the  TCB  is  based  on  a  clearly  defined  and  documented  formal  .security  policy 
model  that  recpiires  the  disci etion.try  and  mandiilory  access  control  (.nlorcement  found  in  class  (Bl) 
systems  to  be  extended  to  all  subjects  and  objects  in  the  ADP  .system.  In  addition,  cineri  channels  are 
addressed.  The  TCB  must  be  carefully  .structured  into  prolection-critical  and  non-protection-critical 
elements.  The  TCB  interface  is  well-defined,  and  the  TCB  design  and  implementation  enable  it  to  be 
subjected  to  more  thorough  testing  and  more  complex  review.  Authentication  mechanisms  are 
strengthened,  trusted  facility  management  is  provided  in  the  form  of  support  for  system  administrator 
and  operator  functions,  and  stringent  configuialion  management  controls  aie  imposed.  The  system  is 
relatively  resistant  to  penetration. 

Class  (B3):  Security  Domains 

The  class  (B3)  TCB  must  satisfy  the  reference  monitor  requirements  that  it  mediate  all  acce.sses  of 
subjects  to  objects,  be  tamper-proof,  and  be  small  enough  to  be  subjccied  to  analysis  and  tests.  To  this 
end,  the  TCB  is  structured  to  exclude  code  not  e.ssenlial  to  security  policy  enforcement,  with  significant 
sy.sicm  engineering  during  TCB  design  and  implementation  directed  toward  minimi/ing  its  comple.xily. 
A  security  administrator  is  supported,  audit  mechanisms  are  expanded  to  signal  security-relevant  cvent.s. 
and  sy.stcm  recovery  procedures  arc  required.  The  .system  is  highly  resistant  to  penetratitm. 


Class  (Al):  Verified  Design 

Systems  in  class  (Al)  arc  functionalK  c(iiii\alcnl  to  those  in  class  (B3)  in  that  no  additional  architectural 
features  or  polic_\  rec|uirenicnts  arc  added.  The  di.stinguishing  feature  of  .systems  in  this  class  is  the 
analysis  derised  from  formal  design  specification  and  \erification  techniques  and  the  resulting  high 
degree  of  assurance  that  the  TCB  is  correcth  implemented.  This  assurance  is  de\elopmenlal  in  nature, 
starting  with  a  formal  model  of  the  security  policy  and  a  formal  top-level  specification  (FTLS)  of  the 
design.  In  keeping  with  extensive  design  and  development  analysis  of  the  TCB  required  of  systems  in 
class  (Al),  more  stringent  configuration  management  is  required  and  procedures  are  established  for 
securely  distributing  the  .system  to  sites.  A  .sy.stem  .sccurit\  administrator  is  supiiorted. 
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